Project Setting: Run Destroy Job Before Branch Delete

Release notes

So that GitLab can function as the Single Source of Truth for DevOps Environment management, environment destruction upon branch deletion is now an enforcable project setting.

Problem to solve

GitLabs innovative approach to creating and updating environments when branches are created or updated should manage the entire environment lifecycle for as many scenarios as possible for environment destruction upon branch deletion.

This would make GitLab into a SSOT for "full lifecycle" environment management and the branch create / destroy APIs could make it the primary API for this process as well.

Intended users

• Delaney (Development Team Lead)
• Sasha (Software Developer)
• Priyanka (Platform Engineer)
• Sidney (Systems Administrator)
• Simone (Software Engineer in Test)
• Allison (Application Ops)
• Ingrid (Infrastructure Operator)
• Isaac (Infrastructure Engineer)
• Cameron (Compliance Manager)

User experience goal

Any deletion of a branch should first trigger an environment destroy job if one exists. Currently deleting a branch results in the environment destroy job failing due to the branch being gone.

If branch delete by git command line is too difficult to intercept, there would still be a huge benefit for the branch delete GUI and branch delete API being able to abide by this proposal. If customer demand for git push branch delete manifests, perhaps a gitlay intercept could be devised - maybe even as simple as creating a copy of the branch as "delete_pending_OLD_NAME".

Evidence of Demand

In various ways, this is a very long requested feature:

• Issue: Stop dynamic environment when associated branch is deleted on merge (3 years)
• Issue: Destruction jobs (`action: stop`) often not triggered on branch/environment deletion (1 year)
• Issue: Auto-close environment when branch is deleted (7 years)
• Issue: Run a pipeline job while the branch is deleted (1 year)

Proposal

1. When an branch delete request comes through an interceptable API call (e.g. GUI, GitLab API)
2. Check if a destroy job is available for the last pipeine for the branch in question.
3. Check if the new setting to always run destroy jobs before deletion is set
   1. If No: Delete immediately (legacy behavior)
   2. If Yes:
      1. Queue the deletion (perhaps UI status "delete pending environment destruction")
      2. Run the destroy job
         1. If the destroy job fails, generate an error and do not delete the branch (status "environment destruction failed, delete cancelled")
         2. If the destroy job succeeds, delete the branch

If necessary, consider a second setting that controls whether the environment destruction job is "best effort" or "required success before delete is allowed"

Further details

This should be behind a setting so that any existing automation around the current branch delete behavior is retained and the new behavior is opt-in.

Example of destroy failure when using GitLab UI to delete branch:

Permissions and Security

Documentation

Availability & Testing

Available Tier

Free tier to keep complete environment support consistent with the partial support that exists today.

Feature Usage Metrics

What does success look like, and how can we measure that?

More adoption of GitLab as the "DevOps Environment Building Engine".

Measure it by making note of an increase in "environment: on_stop" keyword usage.

What is the type of buyer?

Any organization that ascribes to the "Production Like" environments talked about at https://12factor.net or the book "Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation"

Is this a cross-stage feature?

No.

What is the competitive advantage or differentiation for this feature?

Full Lifecycle Environment Management that includes destruction solves a massive IT Cost + Developer Friction problem. When not managed as a Full Lifecycle, environment management creates friction for developers because they engage in environment sprawl, so their IT group raises process barriers to control costs. The negative reinforcing cycle then begins as developers continue to not delete environments due to the difficulty in getting them and IT makes it more difficult to justify and deploy them due to environment sprawl. This even more true in Cloud cost sprawl where there are no physical limits to how many environments can be spun up.

With some relatively moderate changes GitLab can become the "Managed Lifecycle DevOps Environment" engine for Developer Platforms of all types.

• When projects have integrated IaC (e.g. Serverless.com Framework, AWS SAM, GitLab AutoDevOps) all environment creation uses the exact same SSOT, production capable IaC for environments.
• Becoming the "Go To" SSOT for Managed Lifecycle DevOps Environments
• Competing with simple needs for Developer Environments
• While also being able to be the Environment Management API behind other Developer Environment engines like backstage.io

Links / references

This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.

This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.

This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.

This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.