To build a CI/CD pipeline, work in eight steps: set the repository and branch rules, build every change, run automated tests, store one artifact, deploy to staging, add release approvals, deploy to production, then build and test a rollback. Each step ends with an output and an owner.
Last reviewed 2026-11-05 by Manish Sharma.
A pipeline is what continuous integration and delivery do: it builds, tests and releases every change automatically. This guide gives the build order for automating your software releases. It covers the order only. It does not cover the cost of slow releases, scoring, tool choice or building the environments. For the tool decision, how to choose CI/CD tools for your firm sets out the questions in order.
How to Build a CI/CD Pipeline: The Order at a Glance
Build from the left of the release path to the right, and put a gate before each stage that follows. One common frame has four CI/CD pipeline stages: source, build, test and deploy. The eight steps split those four so that nothing is skipped.
The table shows the output of each step and its owner. Owners are roles, so you can match them to people in your firm. The rules are practical advice, not measured results.
| Step | Output | Owner |
|---|---|---|
| 1. Repository and branch rules | Written rules and a protected main branch. | Engineering lead. |
| 2. Build from a clean copy | A build that passes on a fresh machine. | Engineering lead. |
| 3. Automated tests | A test stage that stops the run when a test fails. | Engineering lead, with the product owner. |
| 4. One stored artifact | A versioned build output in a store with a retention rule. | Release owner. |
| 5. Staging and acceptance tests | A staging stage that opens the next stage only on a pass. | Release owner. |
| 6. Release approvals | An approval gate with a named owner and backup. | Product owner. |
| 7. Production and smoke test | A production stage that checks itself. | Release owner. |
| 8. Rollback | A rollback step with a dated rehearsal record. | Release owner. |
Step 1: Set Up the Repository and Branch Rules
Keep one repository for each deployable product, protect the main branch, and require a review before any change merges. The protection should block three things: direct pushes to main, merges while checks fail, and merges with no named reviewer.
Store the pipeline definition in the repository as files. Then it gets reviewed like any other code, and its history shows who changed a stage and when. Keep configuration values out of the repository, because they differ for each stage. Secrets need their own handling, and one rule is enough here: they do not go in the repository.
Write the branch rules on one page, and keep them next to the repository. Name who may approve a merge, which checks must pass first, and who may change the rules. Rules that live only in a person’s head can break once work gets busy.
The output is a short set of written rules and a protected main branch.
Step 2: Build Every Change From a Clean Copy
A build starts from a fresh copy of the code on a clean machine. It installs pinned versions of every dependency, then either produces a build output or stops the run with a message to the author.
Before you automate anything, test the build by hand on a fresh machine. If it fails there, a pipeline will only repeat the failure faster. This is a sound way to set up a basic CI/CD pipeline that you can trust.
Commit the files that pin versions, so the same dependencies install on every run. Also use the same tool versions on laptops and in the pipeline, so results match in both places. When they differ, a change can pass on one laptop and fail in the pipeline, and nobody can say why.
The output is a build that passes from a clean copy, run by the pipeline on every change.
Step 3: Add Automated Tests That Gate the Run
Run fast checks on every change before it merges: the build, code analysis and unit tests. Run the slower integration tests after the merge. They cost more, and a pass before the merge does not prove a pass after it.
A failing test stops the run. The team does not skip it to save time, and a skip needs a written reason from the engineering lead. If a test fails at random, fix it or take it out of the gate.
Also, tests must not depend on one person’s machine. Give them their own data, set up the same way on each run.
The output is a test stage that fails the run.
Key Takeaway Steps 1 to 3 give you a protected branch, a clean build and a test stage that stops bad changes. Nothing after them works without these.
Step 4: Store One Artifact and Promote It Unchanged
Build once, store the output under a version, and deploy that same output to every later stage. What was tested is then what ships. Rebuilding for each stage risks different dependencies or settings, so a build that passed in test is not the build that reaches users.
Name each artifact with the change identifier and the build number. Then it traces back to one commit, and anyone can see what is running in a given stage. Keep artifacts in a store with a retention rule, so old versions stay available for a rollback.
Settings differ for each stage, so apply them at deploy time and do not bake them into the artifact. The same file then moves from stage to stage with only its settings changed.
Microsoft Learn’s baseline pipeline architecture describes this flow: tested output moves to staging, acceptance tests run, and an approval can come before production.
The output is an artifact store with a naming rule and a retention rule.
Step 5: Deploy to Staging and Run Acceptance Tests
The release stage takes the stored artifact and deploys it to a staging area. Staging should mirror production closely enough that you trust what it shows. Building or matching the environments themselves is a separate piece of work, and this guide treats staging as one stage of the release path.
Once the artifact is in staging, run acceptance tests. These check that the product does what the business expects, such as a customer completing an order or a user signing in. Only a pass opens the next stage. A fail stops the run and goes back to the author.
Apply the staging settings at deploy time, as set out in Step 4. Keep secrets out of the artifact and out of the logs. One line is enough here: the pipeline reads them from a secure store when it runs.
Also record the result of every staging run, because the approver in Step 6 needs to see it.
The output is a staging stage that opens the next stage only on a pass.
Step 6: Add Release Approvals With a Named Owner
Put one approval before production. Give it to a named role, with a named backup, so a release does not wait on one person’s leave.
Show the approver four things: what changed since the last release, the test results, the staging result and the rollback status from Step 8.
An approval is a decision by the person who owns the outcome, made on evidence the pipeline has produced. It does not hand the release to another team to test everything again.
Decide in advance when an approval is skipped. One option is a low-risk change class agreed in writing. That is the firm’s own decision, so write down who agreed it and what falls inside it. Keep a record of who approved what, and when.
A cancelled approval ends the run and can trigger the rollback in Step 8.
The output is an approval gate with an owner and a record.
If the rollback has not been rehearsed, say so on the approval screen. The approver then weighs the risk with the facts in view.
Step 7: Deploy to Production and Run a Smoke Test
Deploy the same artifact that passed staging, then run a short smoke test straight away. A smoke test checks only that the product is up and its main paths respond. It is short and does not replace the acceptance tests in staging.
Choose a release method that suits the system: all at once, in small groups, or alongside the old version. The right choice depends on the product, its users and how easily it can be reversed. Record the choice for each product so the team knows what to expect, and no one method suits every case.
A failed smoke test triggers the rollback in Step 8. The pipeline already knows what to do, so the people on call do not have to decide in the moment.
The output is a production stage that checks itself.
Step 8: Build and Test the Rollback Before You Need It
A rollback is a step in the pipeline that puts the previous artifact back. Because Step 4 keeps old versions, the pipeline has something to restore. Rehearse the rollback in staging on a schedule, so you know it works.
Write down what it restores. Code comes back with the old artifact, but data changes need their own plan. Options include a step that reverses a change, or releasing data changes in two stages. Write who can trigger it and how long the last rehearsal took.
Triggers should be clear: a failed smoke test, a cancelled approval or a failed release. Also, a rollback that fails when it is needed is the pain described in our guide on slow releases.
List what the rollback restores, who can trigger it and where the steps live in the pipeline.
Run it in staging on the schedule your team sets, and time it.
Note the date, the duration and anything that broke.
Correct the steps that failed, then rehearse again.
The output is a rollback step with a dated rehearsal record. Once the pipeline is running, you can score it against 12 pass or fail checks with a pass rule and evidence.
Five Mistakes People Make When They Set a Pipeline Up
Five mistakes undo a new pipeline. Each has a fix in an earlier step.
| Mistake | Why it bites | Fix |
|---|---|---|
| Rebuilding for each stage | The build that shipped is not the one tested. | Build once, promote it (Step 4). |
| A gate skipped on the release branch | A change reaches users unchecked. | Same rules on every releasing branch (Steps 1 and 3). |
| Versions differ between laptops and the pipeline | A change passes in one place and fails in the other. | Pin versions, use the same tools (Step 2). |
| A rollback written but not rehearsed | Nobody knows if it works until a release fails. | Rehearse it, keep the record (Step 8). |
| A pipeline with no owner | Stages drift and nobody answers for it. | Name an owner for each step (Step 6 and the table). |
For the business side of the same problem, read what slow releases cost a business.
Key Takeaway Build once, gate each stage, name an owner for each step, and rehearse the rollback before you rely on it.
Signisys can look over your plan for these eight steps with you. We deliver this work through our DevOps and IT automation services, and the wider method is on the DevOps and CI/CD automation solution page.
How to Build a CI/CD Pipeline FAQ: Questions Before You Start
How do you build a CI/CD pipeline from scratch?
How to build a CI/CD pipeline in a business with several teams?
How long does it take to build a CI/CD pipeline for the first time?
Which two steps should come before any automatic release to production?
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.