Getting started
Guides and examples
Reference documentation
Background concepts
Frequently Asked Questions
Integrations
Stages of Workflows
There are currently four types of stages in the workflows Release offers:
Build
Builds are not really a stage of the workflow that can be configured in Release, however, this is the first step that is always run before the other stages can be executed. There is some confusion about the build stage that happens because the word "build" is ambiguous. In this case, the Build stage refers to the stage where we run one or more
docker build command(s). (It's more complicated than that: we use buildkit and a lot of heavy machinery under the covers.)Setup
The setup stage is the beginning of the lifecycle of an environment. The setup stage creates the infrastructure and objects for all of the supporting pieces that are necessary for the fully functioning environment to be constructed. This stage must occur at least once before the patch stage can be successful. This setup stage must also be performed any time a change occurs in either the Application Template or in the Environment Variables Template.
Notice we are avoiding the use of terms like "building" and "deploying" and so forth to avoid confusion and overloading these terms even more. The setup stage can be thought of as the "birth" of the environment. However, the setup stage can be run multiple times to apply changes made in the Application Template or Environment Variables Template. Sometimes the setup stage is run manually to "rebuild" an existing environment that might be out of sync with the Release version for whatever reason (perhaps from manual intervention, or from some unforeseen failure or restart in Kubernetes, etc.)
After the initial infrastructure is created (like databases and load balancers), then the code is deployed. This might cause some confusion between the stages of setup and patch, but the initial code deployment has to happen during the setup stage so that the environment is fully running when the setup is complete. To further complicate matters, the setup involves what some software engineers think is a build and deploy step (for example, using
yarn build or assets creation and uploading) but this is actually a runtime step where we issue one or more docker run command(s). (It's more complicated than that: we use Kubernetes and very heavy machinery under the covers.)Patch
The patch stage is only run after successful builds and setups are performed. Generally, an environment will be created with Setup and then new code is deployed or updated with the patch workflow. A patch can be triggered from a git push to the same tracking branch for the environment, or it can be triggered manually from the deploy button on either the Environment Details page or the Build Details page.
The patch stage is a more traditional "deploy" stage where code is updated and jobs are run. One key difference is that the initial heavy lifting done by the setup stage would already have been done so that subsequent builds and deploys can skip previous infrastructure steps that were already completed. For example, there is no need to initialise databases or create load balancers in this step.
Teardown
The teardown stage is run when an environment is either expired or is deleted. This stage can be used to remove any extra infrastructure or permanent entries or storage created somewhere else that Release is not aware of. Typical use cases include destroying infrastructure created with Terraform or Pulumi, or deleting/dropping tables in a shared database or storage system.
Last modified 3mo ago