A useful CI/CD pipeline for a small team connects a source change to a checked release, a deliberate deployment and a verified user journey. Begin with one application and a process another authorised maintainer can operate. The first goal is a release you can identify, explain and recover from under agreed conditions.
You do not need to start by changing cloud providers or buying a larger toolchain. Walk through the last real release. Record which steps depended on a developer's laptop, an undocumented credential or a remembered command. Those gaps make a more useful first brief than a diagram of tools nobody has agreed to maintain.
Continuous integration brings changes together frequently with checks that expose integration problems. Continuous delivery keeps the software in a releasable state through a repeatable process. Continuous deployment goes further by automatically releasing changes that meet the defined conditions. DORA's continuous-delivery guidance makes the distinction between delivery capability and deploying every change automatically.
Decide where the production release decision belongs. A reviewed release window can fit a delivery pipeline. So can automated deployment where the application, checks and recovery controls support it. Write the decision down: what starts a build, what can reach production, who can authorise it and what stops it.
For a hypothetical booking application, the first scope might cover its web app and background worker, one test environment and one production environment. A separate mobile client or customer-data migration remains outside that first workflow unless explicitly included. This example illustrates a scope boundary, not a delivered client system.
Keep a short release record that points to the detailed evidence. Someone responding to a problem should be able to identify the deployed revision without asking the person who built it. Avoid treating a branch name, which can move, as the complete release identity.
Use this original worksheet for the first rehearsal. Replace the examples with your application's actual references and owners. It is a record of decisions and evidence, not a requirement to adopt a particular CI platform.
| Record | What to capture | Why the operator needs it |
|---|---|---|
| Source | Repository and exact revision | Identify the code behind the candidate |
| Build | Package or image identifier and build inputs | Locate the release that was checked |
| Checks | Required results and links to failures | See which acceptance conditions were evaluated |
| Configuration | Target environment and configuration version | Explain differences without copying secrets into the record |
| Data change | Migration reference and compatibility notes | Know whether an older application can still operate |
| Release decision | Authorised person or rule, time and target | Trace why this candidate reached this environment |
| Verification | User-flow result, relevant signals and recovery reference | Decide whether to continue observing or act |
DORA's deployment-automation guidance supports using a consistent deployment process and traceable build artefacts across environments. Where the platform permits it, promote the checked artefact rather than rebuilding an unidentified replacement. Keep environment configuration separate where supported and version its templates without exposing credentials.
Some frameworks embed environment values during the build. Document that constraint rather than claiming the test and production files are identical. Record the separate build inputs and decide which checks must run on the actual production candidate. Reproducibility depends on the process your application really uses.
Choose checks around plausible failures and important behaviour. A type or syntax check may catch an invalid change; an application test may verify a calculation; an integration check may reveal a broken dependency contract. Their value comes from the failure they expose, not from the number of green badges.
For the booking example, useful cases could include an authorised booking, a rejected unauthorised request and a retry that must not create a duplicate. Use suitable test data and supported test integrations. The same list would not automatically fit a brochure website or an inventory application.
Make failures readable. A maintainer should know which step failed, which revision it used and where to find a redacted diagnostic record. Distinguish a broken check from a defect in the application. Repeatedly bypassing an unreliable check leaves the pipeline with a misleading appearance of protection.
Treat a successful deployment command as one stage. Azure's safe-deployment guidance describes health checks and recovery decisions around rollout. Select verification that reflects the application: a page responding successfully does not prove that a booking, payment callback or background job completed correctly.
Keep production credentials out of ordinary test jobs and source control. Give each workflow only the access its task needs. Review third-party workflow dependencies and their update process. GitHub's secure-use reference covers dependency controls, minimum permissions and the risks of executing untrusted code in privileged workflows.
Where the cloud provider supports it, OpenID Connect can exchange an authorised workflow identity for a short-lived cloud token. It still requires a configured trust relationship and suitably restricted cloud permissions. Enabling a token request without constraining who can use the role does not establish the intended access boundary.
Confirm the controls available in the actual repository and plan. GitHub's deployment environments reference documents availability limits: on Free, Pro and Team, required reviewers are available for public repositories. Do not promise that a private repository has every approval feature because it can define an environment.
An environment label also does not create a separate cloud account, database or network. Record the real separation. Include deployment concurrency: decide how a second release waits or is rejected, and whether interrupting the current operation is safe. Cancelling a job halfway through a data change needs explicit handling.
Agree the response before the first live rehearsal. The following original matrix gives a team concrete cases to walk through. Replace each role with a named owner and keep the escalation route available outside the pipeline itself.
| Failure case | First decision | Evidence and owner |
|---|---|---|
| Required check fails | Stop promotion and inspect the cause | Check output; application maintainer |
| Cloud access is denied | Inspect the intended identity and permissions | Redacted authentication result; access owner |
| Another release is active | Follow the agreed queue or rejection rule | Active release record; release operator |
| Deployment stops partway | Establish actual state before retrying | Platform and application state; operator |
| Important user flow fails | Follow the release-specific recovery decision | Flow result and data compatibility; recovery owner |
| Alert cannot reach its recipient | Restore the notification path and name cover | Delivery evidence; operating owner |
Recovery may mean restoring an application version, disabling a feature, repairing forward or restoring data through a separately rehearsed process. AWS's schema-compatibility guidance explains why old and new application behaviour must be considered around data changes. Reverting code does not undo every write or external action.
Use the rollback-plan worksheet to record the compatible target, recovery decision and checks for a specific release.
Ask a second authorised maintainer to release a known change, diagnose a deliberately failed check and follow an applicable recovery scenario. Record where the instructions were insufficient. Keep workflow files, access ownership, dependency updates and the release runbook in the handover scope.
Agree who watches the result and for what period. A configured alert does not create staffed incident response. Review your existing hosting responsibilities and application agreement before buying overlapping work. If the release difficulty comes from a tightly coupled legacy system, the staged-modernisation guide may identify a necessary application change.
Bring a recent release record and the most troublesome manual step to a DevOps and release-process review. The proposal should name the applications, environments, checks, recovery rehearsal and operating owners. A bounded workflow that the team can explain is a useful starting point for the next improvement.
