Stages of workflows

There are currently four stages in the Release workflow:

The build stage

The build stage in Release is when the docker build commands are run. It's the first step that must take place before any other stages can be executed. You can't configure the build stage in Release.

The setup stage

The setup stage is the beginning of the lifecycle of an environment. In this stage, Release issues docker run commands, creates the infrastructure and objects that are necessary for the fully functioning environment to be constructed, and then deploys the code.

This initial code deployment takes place during the setup stage so that the environment is fully functional when the setup stage is complete.

The setup stage must run at least once before the patch stage, and again whenever the Application Template or Environment Variables Template is changed to apply changes.

The setup stage can be run manually to rebuild an existing environment that is out of sync with the Release version, which may occur due to some unforeseen failure or restart in Kubernetes.

The patch stage

The patch stage is only run when the build stage and setup stage have been completed. This is the stage at which new code is deployed or updated.

A patch can be triggered from a Git push to the same tracking branch for the environment, or it can be triggered manually using the Deploy button on the Environment Details page or the Build Details page.

The patch stage is somewhat like a traditional "deploy" stage, when code is updated and jobs are run. The key difference between Release's patch stage and a traditional deploy stage is that the patch stage does not need to do any of the heavy lifting of setting up necessary infrastructure, as this will have been completed in the setup stage. For example, in the patch stage, there is no need to initialise databases or create load balancers.

The teardown stage

The teardown stage is run when an environment is either expired or deleted. You can use the teardown stage to remove any extra infrastructure, permanent entries, or storage created elsewhere that Release is not aware of. For example, you can use the teardown stage to destroy infrastructure created with Terraform or Pulumi, or to delete or drop tables in a shared database or storage system.