CI/CD Pipeline Setup: Step-by-Step Guide for DevOps Teams

• A good pipeline is typically the first budget item to yield dividends with any DevOps investment.
• Good CI/CD minimizes manual effort, surface bugs early, and makes releases less painful.
• The main workflow is quite straightforward: trigger, build, test (possibly even store artifacts), deploy, monitor.
• Start small. A simple first pipeline is better than a complicated one no one trusts.
• Choose the one that matches your stack, team size and hosting model.
• Secrets, branch rules, and environment separation matter from day one.
• Fast feedback matters more than fancy pipeline logic.
• The best pipeline is clear, repeatable, and easy to fix.

A good CI/CD pipeline setup is one of the first DevOps moves that creates visible value. It streamlines in time, reducing release risk while providing the team with a repeatable path from commit to deploy. When teams are in the habit of skipping this work, it often catches up with them later in the form of broken builds, laborious manual deploy steps, and late-night hotfixes.

GitLab defines CI/CD as an end-to-end automated workflow that builds, tests and deploys code changes with reduced manual effort, and this is precisely why it becomes such a winning practice so early in growing teams.

This guide covers a practical CI CD pipeline setup guide for teams that want a real pipeline, not a diagram for slides. It walks through tool choice, branch triggers, builds, tests, deployments, and alerts. It also points out the mistakes that often slow down a first CICD pipeline setup. If you need a broader view beyond pipeline setup, this DevOps Implementation Roadmap shows how CI/CD fits into a wider delivery strategy.

This article is for developers working on their first pipeline, DevOps engineers cleaning up a legacy one, and engineering managers looking to setup CI/CD pipeline work easily without it turning into a months-long infrastructure project.

A CI/CD pipeline is an automated multi-stage flow from version-control of code to build, test and release. According to GitLab, CI integrates changes in frequency and automates validation of those integrations; CD brings validated code to production-ready status, or with continuous deployment can automatically push changes live after passing validation.

In simple terms:

• Continuous Integration means developers merge small changes often, and the system builds and tests them.
• Continuous Delivery means the system keeps code ready for release.
• Continuous Deployment means approved code can ship automatically to production.

That difference matters when you configure CI/CD pipeline stages. Some teams want manual approval before production. Others want a fully automated release path. For a more technical breakdown of how pipelines are structured and executed, see the official GitLab CI/CD docs.

Every working pipeline has a few basic parts.

But the pipeline starts with an event happening in source control. It can be a push, pull request, merge request, or tag or manual run. Both GitHub Actions and GitLab CI use YAML-based workflow definitions attached to specific events in your repository.

This stage builds the app, installs dependencies, packages containers, or builds deployable artifacts. In the case of Docker, this is typically where the image is built and tagged.

Tests should run automatically. Start with unit tests. Add integration and smoke tests as you scale the pipeline. Your first CI/CD pipeline configuration should not have every test in the universe running on it, but what it must do is have the tests that are gatekeepers of preventing bad code from entering our projects.

Build packages, Docker images, logs and test results are examples of artifacts. Keep them somewhere the following stages can access. That keeps releases repeatable.

This stage moves the tested artifact to staging or production. For many teams, the first safe pattern is staging first, then a manual approval gate for production.

A pipeline is not finished after deploy. You need alerts, logs, dashboards, and failure notifications. Slack alerts and on-call routing make sure somebody sees a broken release quickly.

The first step in any CI/CD pipeline setup is tool selection. Do not overthink it. Pick the option that fits your code host, team habits, and infrastructure model.

• GitHub Actions fits teams already on GitHub. Workflows live in .github/workflows, use YAML, and can run on GitHub-hosted or self-hosted runners. Public repositories and self-hosted runners are free. Private repositories get included minutes by plan, then usage-based billing.
• GitLab CI/CD caters to the teams that prefer source control and pipeline logic at one place. Pipelines are defined in .gitlab-ci.yml. GitLab has Free, Premium and Ultimate plans (Free is $0 per user/ month; Premium at $29 per user/month, billed annually).
• Jenkins fits teams that want full control and do not mind running infrastructure. Jenkins is an open-source automation server and supports Pipeline as Code through Jenkinsfile.
• CircleCI is a strong hosted choice for teams that want usage-based pricing. Its current Free plan lists 6,000 build minutes and up to 5 active users, while paid plans start at $15 per month.
• Argo CD is a GitOps delivery tool for Kubernetes. It works well when Git is your source of truth for deployment state. It is open source and self-hosted.

A simple rule helps here: if you already live in GitHub, start there. If you already live in GitLab, start there. If your team wants a cleaner deployment model based on Git as the source of truth, this Git-Centric Approach explains why GitOps works well for modern CI/CD workflows.

The next step in how to set up CI/CD pipeline work is connecting the repo triggers to clear branch rules.

Start with a basic branch strategy:

• Run CI on every pull request or merge request
• Run full deploy checks on main
• Trigger production deploys only from protected branches or tags

GitHub supports event-based workflow triggers and environment controls. GitLab supports pipeline events, variables, protected branches, and protected runners. Those controls matter when you configure CI/CD pipeline rules for real teams, not just solo projects.

The build stage should be boring and predictable.

Keep it simple:

• Install dependencies
• Restore cache
• Build the app or image
• Save the artifact

If you use Docker, add a clean Dockerfile. If you use compiled languages, make sure the build command works locally and in CI. GitHub and Jenkins both support pipeline-as-code patterns that make build steps easy to version and review.

This is where many teams first hit trouble with CI CD setup. They mix local-only scripts, hardcoded paths, and missing cache steps. Fix that early.

A first pipeline does not need huge test coverage, but it does need useful coverage.

Start with:

• Unit tests on every commit
• Integration tests on key services
• Smoke tests after staging deploy

GitLab notes that CI/CD pipelines test code at each stage and stop early when a job fails. That is exactly what your first pipeline should do. Fail fast, fix fast, move on. 

This is the point where many teams ask how to set up CI/CD pipeline stages for multiple environments without making a mess.

Use a simple flow:

• Deploy automatically to staging
• Run smoke tests
• Require approval for production, if needed
• Keep environment variables and secrets outside repo files

GitLab warns against storing sensitive values in .gitlab-ci.yml and recommends protected and masked variables or external secret managers. GitHub also supports environment secrets and deployment environments.

A clean CI/CD pipeline configuration keeps staging and production separate. It also keeps secrets out of code.

A deployment without visibility is just a guess.

At minimum, add:

• Pipeline failure alerts
• Deployment success or failure messages
• Application health checks
• Dashboard links for logs and metrics
• On-call routing for production failures

This part often gets skipped in an early setup CI/CD pipeline project. That is a mistake. If the release breaks and nobody sees it, the pipeline did not really help.

The pricing snapshot below is based on current vendor pages and official docs. Check those pages before final buying decisions, because vendors change packaging and usage limits over time.

A good CI/CD pipeline should make delivery simpler, not harder to understand. That is where clear structure and repeatable workflows start to matter.

In practice, the best pipelines do not try to be clever. They help teams move faster, with less guesswork and fewer release risks.

Use this as a quick checklist:

• No branch protection
• Slow builds with no caching
• Tests that only run before release
• Secrets stored in repo files
• One pipeline for every environment, with no separation
• No artifact retention plan
• No alerts after deployment
• No rollback path
• Too many manual steps
• A complex first design instead of a small working pipeline

Most early CI CD setup problems come from trying to do too much at once.

If your team needs help with a first CI/CD pipeline, AppRecode already positions this work around audits, branch strategy, environment design, automation, security controls, and ongoing optimization. 

• CI/CD consulting covers pipeline audits, architecture, best practices, and security by design. 
• DevOps solutions widen that into infrastructure and delivery support. 
• DevOps health check focuses on bottlenecks in CI/CD, monitoring, cloud setup, and cost control. 
• For ML teams, MLOps development and MLOps consulting extend the same discipline to model delivery.

You can also review AppRecode’s client feedback and delivery track record on Clutch.

A good CI/CD pipeline is not about shiny tooling. It is about making delivery repeatable. Start with clear triggers, a stable build, useful tests, safe deployments, and visible alerts. Then improve from there.

The CI CD pipeline setup guide above should provide you with a clean slate to work from. Keep the first version simple if you need to tweak CI/CD pipeline stages for teams or environments. A straightforward pipeline that functions is better than an intelligent pipeline that fails.

I would set up the first CI/CD pipeline as a narrow working path, not as a grand redesign. Pick one app and make one route from pull request to staging. If that route works every day, you can grow it.
Start with source control. The pipeline should run when someone opens a pull request, pushes to main, creates a tag, or starts a manual release. Then add the build step. It should create the same thing you will deploy later: a package, static build, binary, or container image.
Next come tests. Begin with the checks that catch real mistakes quickly. Unit tests first, then integration or smoke tests where they make sense. Keep the output, logs, and artifacts so failures can be understood.
For deployment, I would begin with staging. Production can wait behind an approval until the team trusts the flow. Add failure notifications and a rollback note. Without those, the pipeline is only half built.

I would choose a CI/CD tool by starting with the mess you already have. Where do developers open pull requests? Where do they look when a build fails? Who is allowed to deploy? Where are secrets stored today? Those answers matter more than a tool ranking.
For a small GitHub team, the easiest answer is often the built-in runner model and workflow files in the repo. For a GitLab shop, keeping pipelines next to merge requests and variables may feel cleaner. A company with old internal systems may still prefer Jenkins because it can be bent into strange shapes.
The Kubernetes part is separate. Argo CD is useful when Git should describe what runs in the cluster. I would pair it with a CI system that builds, tests, and publishes the artifact.
Do not ignore maintenance. Hosted tools save ops time, self-hosted tools give control, and both can fail. Pick the tool your team can debug quickly when a release is blocked.

A basic CI/CD pipeline can be useful within a few days if the app is already in decent shape. By decent, I mean it builds on a clean machine, has at least some tests, and does not depend on secret steps from one developer’s laptop.
If those basics are missing, the calendar changes. You may spend time fixing scripts, creating a Dockerfile, choosing artifact storage, setting up runners, splitting staging from production, or writing down the release process for the first time.
For one small service, I would expect days for the first trusted path. For several services, multiple environments, approvals, secrets, infrastructure access, and rollback rules, think weeks. Regulated or legacy systems can take longer because every shortcut has to be checked.
The mistake is waiting for the perfect pipeline. Ship the thin version first: build, test, deploy to staging, notify on failure. Then improve it once the team is using it for real work.

A useful CI/CD pipeline needs just enough structure to remove guesswork. I would expect a trigger, build step, tests, artifact storage, deployment, and notifications. That is the backbone.
The trigger says when the pipeline starts: pull request, merge request, push to main, tag, schedule, or manual release. The build step should create the same artifact every time. If production runs a container image, build and tag that image once, then promote it. Do not rebuild something different during release.
Tests should fail early. Unit tests catch quick mistakes. Integration, security, smoke, or end-to-end tests can sit where they protect the release without making every commit painfully slow.
Deployment should treat staging and production differently. Production often needs protected branches, approvals, or environment rules. Finally, add alerts. A red pipeline that nobody sees is not a safety net. It is just a red icon buried in a tab. That small detail prevents chaos.

For multiple environments, I would separate the boring things first: variables, secrets, permissions, and promotion rules. Staging and production should not share a loose pile of configuration.
Use environment-specific secrets and variables. GitHub Actions has repository, organization, and environment secrets. GitLab has CI/CD variables that can be masked, protected, and scoped. Use those instead of copying credentials into YAML or passing production secrets to every job.
Then decide how code moves forward. Development might deploy automatically. Staging might deploy from main. Production may require a tag, protected branch, or manual approval. The exact rule can vary, but it should be written down and enforced by the pipeline.
Access should be different too. A staging deploy identity should not casually change production. Logs and alerts should show which environment changed and which commit was deployed.
Finally, rehearse rollback. Multiple environments help only if the team can move safely without mixing configs or databases.

Secrets in CI/CD should be treated like something the pipeline borrows, not something the repo owns. Do not put tokens in YAML, commit them “temporarily,” bake them into images, or print them while debugging.
Use the platform’s secret store or a real external secret manager. GitHub Actions can store secrets at repository, environment, and organization level. GitLab can use CI/CD variables, including masked and protected variables. For cloud access, I would prefer OIDC or short-lived identity when the provider supports it, because long-lived keys tend to spread.
Scope secrets tightly. A test job usually does not need production deploy rights. A forked pull request should not receive sensitive credentials. A staging workflow should not quietly carry production tokens.
Also check the logs and artifacts. Secrets can leak through command arguments, debug output, crash dumps, or copied files. Good secret handling is not a checkbox. It is something you keep auditing as the pipeline grows.

The most common mistake is trying to look mature before the pipeline is useful. Teams add many stages, clever conditions, and fragile scripts, then developers avoid the whole thing because nobody trusts the result.
The boring mistakes hurt more. Builds work only on one laptop. Tests run too late. Branch protection is missing. Secrets sit in repo files. Staging and production use the same credentials. Artifacts are rebuilt instead of promoted. Nobody knows how to roll back. Failure alerts go to a channel everyone muted.
Slow feedback is another killer. If a simple pull request takes ages to validate, developers stop treating CI as part of normal development. Some slowness is real testing cost, but a lot comes from bad caching, duplicated jobs, and checks that run at the wrong time.
I would fix the workflow before blaming the tool. Moving the same confusion from Jenkins to GitHub Actions will not make releases safer. Clear rules come first.

A good CI/CD pipeline feels boring in the best way. Developers push changes, get fast feedback, fix failures while the context is still fresh, and deploy without turning release day into a ceremony.
The first signals are simple. How long does the pipeline take? How often does it fail for real reasons versus flaky reasons? How often do developers rerun jobs without changing code? How many manual steps remain? Can the team trace a production deploy back to a commit and artifact?
Then look at release health. Smaller batches, fewer hotfixes, fewer rollback surprises, and faster recovery usually mean the pipeline is helping. If deployments are automated but incidents are increasing, the pipeline may be moving risk faster, not reducing it.
Security and auditability matter too. Secrets should be controlled, production should have clear approval rules, and logs should show who changed what.
I would ask the team one blunt question: when the pipeline is red, do people trust it? If not, improving trust is the next CI/CD task.