Releases and deployments
Save a release, follow its execution, and handle approvals or recovery with care.
On this page
A release records what you intend to run. A deployment records one execution of that release in an environment. Steps run sequentially, and a failed step stops normal progress.
Save and update a release
Open your project’s Releases page and enter a unique version. Select Create Release to save the current steps and variables. You can also record source and build details in the optional provenance fields. Keep credentials out of those fields.
After changing steps or variables, choose one of these actions:
- Create a new release to keep the previous release configuration available.
- Refresh an existing release to replace its saved configuration for future deployments.
Refresh does not change existing deployment snapshots. It waits until active work, uncertain cleanup, and buffered agent logs are resolved. If the release has a package, refresh also downloads and validates that package again.
Select an environment
Choose Deploy, then select the release and environment.
An assigned lifecycle can require successful deployment to an earlier environment first.
For example, a release may need to pass test before it can reach production.
DurpDeploy queues work for each project and environment pair. If another operation owns that pair, new work waits. An approval wait or unconfirmed cleanup can keep the pair occupied.
Follow logs and verification
Open the deployment to see its steps, attempts, execution location, and live output. If the stream disconnects, reopen the page to reconnect and inspect retained logs.
An administrator can configure environment verification checks. These checks run after the deployment steps. Inspect their results before treating the deployment as ready.
Review approvals
Some lifecycle stages require administrator approval. Wait for an administrator to approve the deployment before execution continues.
Artifact approval adds a review between a planning step and an apply step. An administrator reviews the generated files before the apply step can use them. This is useful for workflows such as Terraform plans. See the artifact approval guide for setup.
Cancel, retry, or re-run
Use Cancel on the deployment page to stop active work. Wait for execution and cleanup confirmation before starting replacement work. Cancellation cannot undo changes a script already made.
Inspect the failed attempt before retrying. A script can partially change a target before it fails. Use scripts that can safely repeat their work.
A re-run keeps the original deployment’s steps and package pin. It uses the release’s current variables. Review those values before re-running an older deployment.
Roll back deliberately
Rollback deploys an earlier successful, different release from the same project and environment. It requires Maintainer permission or higher. DurpDeploy runs that release’s scripts and the environment’s current verification checks.
Rollback does not automatically reverse database changes or restore files changed by scripts. Prepare and test your application’s recovery procedure before using it in production.
Keep useful history
Deployment logs help explain what ran and why it failed. Deleting a release also deletes its deployment history, logs, and schedules. Check retention needs before confirming deletion.