How-to
How to Build a CI/CD Pipeline: 7 Steps From Commit to Release
- Build and test
- Deploy
- Loglune
On this page
- 01What a CI/CD pipeline covers: integration, delivery, and deployment
- 02Before you build the pipeline
- 03How to build a CI/CD pipeline in 7 steps
- 04Editorial example (not a customer case): a CI/CD pipeline for a web API
- 05Continuous delivery pipeline vs. continuous deployment pipeline
- 06CI/CD automation and software: what to automate first
- 07Troubleshooting a CI/CD pipeline
- 08FAQ
- 09Deciding how far to automate your pipeline
A CI/CD pipeline is the automated path a code change takes from a merge to running software. Continuous integration (CI) builds and tests every commit on one shared mainline, and continuous delivery (CD) keeps each passing build releasable and moves it through staging to production. This guide builds a pipeline in 7 steps: merge daily, build and test every commit, promote one artifact, deploy automatically, separate deploy from release with feature flags, roll out gradually, and record which flag value each customer received.
The steps fit web services and APIs that ship from one mainline several times a week. Mobile apps that pass store review and software that customers install as numbered versions need extra release steps, which this guide leaves out.
What a CI/CD pipeline covers: integration, delivery, and deployment
A CI/CD pipeline combines three practices that differ in how far automation goes. Martin Fowler’s article Continuous Integration (updated January 18, 2024) defines continuous integration as each team member merging changes into the shared codebase at least daily, with every integration verified by an automated build that includes tests. Fowler’s article also describes the aim of continuous delivery as keeping the product in a state where the latest build can be released.
The site continuousdelivery.com defines continuous delivery as the ability to get changes of every type, including new features, configuration changes, bug fixes, and experiments, into production or into users’ hands safely, quickly, and sustainably. Fowler describes continuous deployment as one step further: every build that passes all automated tests in the pipeline is released to production automatically, and continuous delivery is a prerequisite for continuous deployment.
| Practice | What runs automatically | Who approves a production release |
|---|---|---|
| Continuous integration | Build and tests on every mainline commit | Not part of the practice |
| Continuous delivery | Build, tests, and deployment to pre-production environments | A person or a written release policy |
| Continuous deployment | Every step through production | The pipeline, when all tests pass |
Fowler also notes that some teams treat continuous delivery as including continuous integration while others treat the two as closely linked partners, and the pair is often shortened to CI/CD. The three terms describe practices, not products, so installing a pipeline tool does not by itself make a team practice continuous integration.
Before you build the pipeline
A CI/CD pipeline needs six inputs decided before the first job runs. A pipeline built without these inputs runs, but the team does not trust its results.
- One mainline branch that every developer merges into, with no long-lived integration branch.
- An automated test suite that the team agrees is allowed to block a merge.
- One build that produces a deployable artifact, such as a container image or a package.
- At least one environment before production, usually called staging.
- A release decision: a person approves production (continuous delivery) or the pipeline releases every green build (continuous deployment).
- A feature flag system, if the team wants to deploy code before customers see it.
How to build a CI/CD pipeline in 7 steps
1. Merge to one mainline at least once a day
Every developer merges into the same mainline at least once a day, because integration problems grow with the time between merges. Fowler’s definition of continuous integration sets the daily merge as the minimum. The DORA capability page on trunk-based development describes developers merging small batches of work into the trunk at least once a day, with branches that last no more than a few hours. A daily merge without an automated build is not continuous integration, so step 1 depends on step 2.
2. Build and test every commit automatically
Every push to the mainline triggers a build and the automated test suite, and a failed run blocks further merges until the mainline is green again. Fowler cites the Extreme Programming guideline of a ten-minute build as a reasonable target. The DORA trunk-based development page says that when the build fails, developers fix the problem immediately, or revert the change when the fix takes more than a few minutes.
A practical order for the commit stage is compile, unit tests, static checks, and packaging. Slower integration and end-to-end suites can run in a second stage after the package exists. A fast commit stage catches fewer defects than a full suite, so the second stage still has to pass before a build reaches production.
3. Build one artifact and promote the same artifact
The pipeline builds the artifact once, tags the artifact with the commit identifier, and promotes that exact artifact from staging to production. Rebuilding for each environment means production runs a binary that never went through the staging checks. Environment differences such as database addresses and API keys come from the environment at deploy time, not from a second build.
The site trunkbaseddevelopment.com makes a related point: short-lived feature branches are used for code review and CI runs, but release artifacts are not created from those branches. Release artifacts come from the mainline.
4. Deploy automatically to staging, then to production
Each green mainline build deploys to staging without a manual step, and production follows either automatically (continuous deployment) or after an approval (continuous delivery). Two common strategies limit the cost of a bad production deploy. Martin Fowler’s note on blue-green deployment (March 1, 2010) describes two production environments kept as identical as possible, with the router switched from the live environment to the new one and switched back for a fast rollback. The Google SRE workbook chapter on canarying releases describes a canary as a partial, time-limited deployment of a change that is evaluated against a control group to decide whether the rollout continues.
A deployment strategy moves a whole version of the service. A deployment strategy does not decide which customers see a feature inside one version, and step 5 covers that decision.
5. Separate deploy from release with feature flags
A release flag lets the pipeline deploy code that stays switched off until someone changes the flag rule. Pete Hodgson’s article Feature Toggles (October 9, 2017) describes release toggles as the most common way to separate feature release from code deployment: incomplete code paths ship to production as latent code and are switched on later. Hodgson also describes release toggles as transitionary. Fowler’s continuous integration article recommends hiding latent code behind a keystone interface where possible and using feature flags for the remaining cases.
In Loglune, a flag edit made in the console or through the API is appended to the change history as a change event that records the customer, the actor, the time, the target flag, and the values before and after the edit. Publishing a flag draft in Loglune creates an immutable version, and the Loglune SDK evaluates that version in your own process or at the edge. The deploy step in the pipeline and the release step on the flag therefore leave two separate records.
Each release flag adds a code path that tests have to cover, and Hodgson calls that overhead the carrying cost of toggles.
6. Roll out gradually with deterministic bucketing
A gradual rollout switches a feature on for a small percentage of users, watches errors and latency, and raises the percentage in stages such as 1%, 10%, 50%, and 100%. A rollout depends on each user staying in the same bucket from one request to the next. The flagd fractional operation (checked September 16, 2026) assigns variants deterministically by relative weight, hashing a key with MurmurHash3 (murmur3), and lists gradual releases among its uses.
Loglune assigns percentage buckets with the same MurmurHash3 hashing as the flagd fractional operation and compares each hash against cumulative weights, so a customer lands in the same bucket in every Loglune SDK language and version. The variant order and the weights together set the bucket boundaries, so change the variant order before a rollout starts, not in the middle of one.
7. Record every flag change and check what a customer received at time T
The final step answers a question that a pipeline log cannot answer: which flag value did one customer receive at the moment a bug fired. A deploy log says which artifact ran at 2:05 p.m. A deploy log does not say whether the new code path was on for that customer, because the answer depends on the flag rule, the rollout percentage, and the customer’s attributes at 2:05 p.m.
The Loglune SDK returns each flag value together with an evaluation record containing the version, the attribute key, and the returned value, and a support ticket or error report can carry that record. To reproduce a report, pick the customer and the time T, or import the evaluation record from the report. Loglune rebuilds the flag state at T from the change history and delivers it in reproduction mode to a development, CI, or staging environment, and one delivery counts as one reproduction. Loglune evaluates time-based conditions at T, not at the time of the rebuild, and production and reproduction use the same evaluation engine.
Loglune reproduces the flag evaluation, not the root cause in application code. A reproduction shows which code path the customer was on, and finding the defect in that code path is still debugging work. The Free plan includes 5 reproductions and stops at the cap (pricing).
Editorial example (not a customer case): a CI/CD pipeline for a web API
The table below fills in the 7 steps for a web API that ships several times a day. The flag name, percentages, and times are illustrative.
| Stage | Trigger | Gate to pass | Output |
|---|---|---|---|
| Commit stage | Merge to the mainline | Compile, unit tests, static checks | Build status in under ten minutes |
| Package | Commit stage green | Image build succeeds | One image tagged with the commit identifier |
| Staging | Image ready | Integration and smoke tests | Staging runs the image |
| Production deploy | Staging green, plus approval | Health checks | Production runs the same image, feature switched off |
| Release | Flag rule edited | Error rate steady at 1%, then at 10% | invoice-export on for chosen customers |
| Investigation | Customer report at 2:05 p.m. | Flag state at 2:05 p.m. rebuilt | Reproduction running in staging |
In the example, the flag invoice-export serves the new code path to enterprise-plan customers and to 10% of the remaining customers by hashed customer key. When a customer reports a broken export at 2:05 p.m., the team rebuilds that customer’s flag state at 2:05 p.m. in staging instead of guessing which bucket the customer was in.
Continuous delivery pipeline vs. continuous deployment pipeline
A continuous delivery pipeline stops before production and waits for a release decision, while a continuous deployment pipeline releases every green build to production. Fowler’s definitions support the split: continuous delivery keeps every build releasable, and continuous deployment releases each passing build automatically. A team with release approvals, fixed change windows, or scheduled customer notices fits continuous delivery. A team with a trusted test suite and feature flags for release control can run continuous deployment, because the flag rule, not the deploy, decides what customers see.
CI/CD automation and software: what to automate first
Automate the steps that run on every commit before the steps that run once per release. The first jobs are the build, the unit tests, and the artifact; deployment to staging comes next; production deployment and flag rollout come last. When comparing CI/CD software, check where jobs run (hosted or on your own machines), how the tool caches dependencies, how many jobs run in parallel, how secrets reach a job, and whether one artifact can be promoted between environments without a rebuild. The criteria come from the 7 steps in this guide, not from a product ranking.
Troubleshooting a CI/CD pipeline
- The commit stage takes longer than ten minutes: move slow suites to a second stage and run tests in parallel, keeping Fowler’s ten-minute guideline for the stage that blocks merges.
- The mainline stays red for hours: fix the broken build immediately, revert the change when the fix takes more than a few minutes as the DORA page describes, and pause new merges until the build is green.
- Staging passes but production fails: confirm that production runs the same artifact tag as staging, then compare environment configuration.
- A customer sees a feature that should be off: check the flag rule and the customer’s evaluation record, then rebuild the flag state at the reported time.
- The same user flips between on and off during a rollout: check that the rollout hashes a stable key such as the customer key, not a session identifier that changes between visits.
- Release flags pile up: add a removal task to every release flag, because Hodgson treats release toggles as transitionary and counts each one as carrying cost.
FAQ
Is CI/CD the same as continuous integration and continuous delivery?
CI/CD is the shorthand for continuous integration and continuous delivery (or continuous deployment) run as one pipeline. Fowler notes that some teams see continuous delivery as including continuous integration and other teams see the two as closely linked partners.
How do you explain a CI/CD pipeline in one sentence?
A CI/CD pipeline is an automated sequence that builds and tests each merged change and moves the passing result toward production. The sequence ends at a release decision under continuous delivery or at production under continuous deployment.
Does a CI/CD pipeline need feature flags?
A CI/CD pipeline runs without feature flags, but without flags the pipeline releases each feature at the moment its code deploys. Feature flags add a separate release step, and Hodgson describes release toggles as the most common way to separate release from deployment.
How often should a CI/CD pipeline deploy?
No single deploy frequency fits every team. The DORA trunk-based development page notes that release branches become unnecessary when a team releases several times a day, and Fowler’s continuous delivery aim is that the latest build can be released. The deploy frequency follows from how small each batch of work is and how fast the pipeline runs.
Deciding how far to automate your pipeline
Start with continuous integration on one mainline, because every later step depends on a green, fast build. Add continuous delivery to staging next, then decide on production: keep an approval when a release needs a person’s decision, and move to continuous deployment when tests and feature flags carry the release decision. Once flags control releases, record every flag change so the team can answer which value a customer received at a given time.
Check which flag value a customer received after a release
Pick a customer and a time T. Loglune rebuilds the flag state at T from the change history and delivers it in reproduction mode to your development, CI, or staging environment. The Free plan includes 5 reproductions.