IT Glossary · Software Delivery
A CI/CD pipeline is an automated sequence that runs every time someone pushes code: it builds the application, runs the tests, checks it for problems, and — if everything passes — packages it and ships it. CI stands for continuous integration (merging everyone's work frequently and verifying it automatically), CD for continuous delivery (keeping it always releasable) or continuous deployment (releasing it automatically). The pipeline is defined as a file in your repository, so the process is versioned alongside the code it builds.
Before CI/CD, integration was an event. Developers worked on separate branches for weeks, then merged, and the merge broke things in ways nobody could attribute to a single change — the phase teams used to call integration hell. Continuous integration attacks that directly: merge small changes frequently, and have a machine build and test every one automatically, so a break is attributable to the change that caused it and is found in minutes rather than weeks. Continuous delivery extends the same logic past the test suite. If every change is automatically built, tested and packaged into a deployable artefact, the software is always in a releasable state and shipping becomes a business decision rather than an engineering event. Continuous deployment goes one step further and releases automatically when the pipeline passes, with no human approval — appropriate for some products and emphatically not for others. Mechanically, a pipeline is defined in a configuration file committed to the repository. In GitLab that file is `.gitlab-ci.yml`; the equivalents are workflow YAML in GitHub Actions and a Jenkinsfile in Jenkins. The file declares stages that run in sequence and jobs that run in parallel inside each stage. A typical arrangement is a build stage that compiles and produces artefacts, a test stage running unit and integration tests plus linting and security scans in parallel, and a deploy stage that pushes to staging automatically and to production behind a manual approval. Jobs execute on runners — agent processes that pick up work and run it, usually inside a fresh container so every run starts clean. Runners are either hosted by your platform (GitLab-hosted runners, billed as compute minutes) or registered by you on your own machines (self-hosted runners, which consume no compute minutes at all). Two mechanics do most of the practical work: artifacts, which pass build output from one stage to the next and are downloadable afterwards, and cache, which persists dependency directories between runs so you are not re-downloading your entire package tree on every pipeline. Getting cache configuration right is routinely the difference between a four-minute pipeline and a fourteen-minute one, and pipeline duration is what determines whether developers actually wait for it or start working around it.
For Indian product and services teams the argument for CI/CD is usually made twice: once internally on release confidence, and once externally by a client. Enterprise and overseas customers now routinely ask about automated testing and release process during vendor due diligence, and an answer that amounts to "a senior engineer builds and deploys manually" reads as delivery risk. The cost side is worth understanding properly before you commit, because it is where teams get surprised. Platform-hosted pipeline runtime is metered — GitLab includes 400 compute minutes a month on Free, 10,000 on Premium and 50,000 on Ultimate, with top-ups at
Related terms: DevOps, DevSecOps, continuous integration, continuous delivery, continuous deployment, GitLab CI/CD, runner, compute minutes, artifact, merge request
Continuous integration is about merging and verifying: developers integrate small changes frequently and every one is automatically built and tested, so breakages are caught immediately and attributed to a specific change. Continuous delivery is about readiness: every change that passes is automatically packaged into a deployable artefact, so the software is always in a releasable state. Continuous deployment — confusingly the other CD — goes further and releases to production automatically with no human approval.
Most pipelines settle on build, test and deploy. Build compiles the application and produces artefacts. Test runs unit tests, integration tests, linting and security scans, usually as parallel jobs so the stage finishes quickly. Deploy pushes to staging automatically and to production behind a manual approval gate. Larger teams add stages for container image builds, database migrations, or post-deploy smoke tests, but those three are the backbone.
A runner is the agent process that actually executes pipeline jobs, normally in a fresh container per job. You can use platform-hosted runners, which require no setup but are metered as compute minutes, or register your own on a VM or physical machine. Self-hosted runners consume no compute minutes at any tier, including Free, so once your pipeline volume is meaningful they usually cost less — and for India-based teams a runner in an India region also cuts job latency.
The practical target is under ten minutes for the pipeline that runs on every merge request, because beyond that developers stop waiting for it and start context-switching, which erodes most of the benefit. The two things that usually get you there are caching dependencies properly so packages are not re-downloaded every run, and splitting the test stage into parallel jobs rather than one long sequential one. Full deployment pipelines can reasonably take longer since they run less often.
A five-person team gets less out of it than a fifty-person team, but the setup cost is now low enough that the honest answer is usually yes. A minimal pipeline that runs your tests and blocks a merge when they fail can be twenty lines of YAML and takes an afternoon. What small teams should skip early is elaborate multi-environment deployment automation and heavy security enforcement — start with tests on every merge request and add stages when a real problem calls for them.