Cloud deployment workflows

A cloud deployment workflow moves an identified change from source control to a verified live service. For each release, the team needs to know what is changing, which version was tested, who may promote it, what users must be able to do afterwards and when to stop the rollout.

Define the release unit

Identify the application version, infrastructure configuration and any data change that belong together. Build a deployable artefact from a known commit and record its identifier. Where the platform permits, promote the same artefact through the environments. Rebuilding it independently for production makes it harder to establish that the tested version is the one released.

Keep a short release record: owner, affected workload, expected user effect, required approvals, artefact version, infrastructure and data changes, and a response if the release fails. The approval route can reflect the impact of the change.

Harness describes a pipeline as a workflow of stages and steps. It can build and test code, publish an artefact, deploy a service, run security checks, manage infrastructure or run feature-flag operations. Retain the artefact identifier in the release record so the candidate being promoted is clear.

Apply a consistent release pattern

Treat every production change as a risk, including application code, infrastructure as code, feature flags and configuration updates. Use a standard deployment pattern and automation to make releases consistent and reduce the chance of human error.

Plan the workflow for routine releases as well as emergency changes such as hotfixes. Prefer frequent, small changes over infrequent, large releases: smaller changes are easier to resolve when problems arise.

Move through clear stages

A common multienvironment sequence is development, test, staging and production. UAT can be added to validate end-to-end business flow, with staging used for final testing immediately before production and made as similar to production as possible.

A pipeline can enforce parts of this sequence. In AWS's CI/CD terminology, continuous delivery has an explicit approval before production, while continuous deployment does not. Whichever approach a team uses, it needs an accountable response when a check fails.

Promote reviewed changes through the pipeline

A common continuous integration path starts with a short-lived feature branch, followed by a pull request to the main branch. A reviewer approves the change before it is merged, and feature branches are not deployed directly to upper environments. This gives the release team a clear point at which the reviewed change joins the source of truth. This is the trunk-based workflow pattern: one main branch is the source of truth, with short-lived feature branches.

Keep environments separate and comparable

Development is for changing software, test is for checking a candidate, and production serves live users. Give each environment appropriate access and data controls. Make test similar enough to production to expose relevant configuration and integration faults. Identical capacity is not always necessary, but a smaller test system cannot establish production load performance.

Record intentional differences in policy, quota, dependencies and data. A passing test does not cover a production-only condition unless that condition is checked separately.

Check the risks introduced by the change

Choose checks that match the release. Application logic may need unit, integration and critical user-action checks. An infrastructure change needs a review of proposed resource operations and affected paths. A database change needs a compatibility check for the application versions that may run during rollout or reversal.

Set pass conditions before running the checks. Record the candidate version, environment, data conditions and result. A plan or test report is evidence for that candidate under those conditions, not a guarantee about every live request.

Release with a stopping rule

Choose a rollout method the service supports. Limited initial exposure can reduce the number of users affected when routing and observation are configured correctly. Watch completed user actions, errors and latency as well as component health. Agree on the observation period, decision owner and condition that pauses further rollout.

Keep the previous usable application version available for the agreed decision window. Shifting traffic or redeploying old code does not undo writes, schema changes or external messages. Decide how those states would be handled before release.

Harness documentation names rolling, canary and blue-green deployments as common strategies, with different rollout behaviour and rollback capabilities. Choose a strategy the service supports and apply the agreed health gate and stopping rule at each phase.

Require a health decision at each rollout phase

For progressive exposure, define a health check before each phase begins. A successful check is the gate to increase exposure; if an issue is detected, halt the deployment immediately and initiate recovery rather than continuing to the next phase. Make the phase decision operational by identifying who evaluates the health result and who can stop the rollout.

Close the change

Record the live artefact and configuration, checks actually performed, observed issues and support owner. Mark skipped checks unassessed. If a deployment fails or stops, review the missing guardrail or unclear decision and update the workflow.

The handover record should let the support owner see the live artefact and configuration, completed checks, observed issues and who is watching for delayed effects. Keep the agreed observation period and stopping condition with that record.