Pipelines are a basic component of both continuous integration (CI) and continuous delivery/deployment (CD). Pipelines ensure that only code that meets certain quality standards makes it into production. CI pipelines make sure that all code goes through the same process and automates tests and builds. Before learning how pipelines work, it’s important know relevant terms.
Commit: A code change.
Job: Instructions for the agent or runner to execute.
Pipeline: A collection of jobs that are divided by stages
Runner: An agent or server that executes each job.
Stages: A keyword that defines phases of a pipeline, such as build and deploy. Jobs within a stage are executed in parallel.
A continuous integration pipeline consists of two things:
In GitLab, CI pipelines are configured using a version-controlled YAML file,
.gitlab-ci.yml, within the root of a project. From there, you can set up parameters of your pipeline:
As code goes through each stage of the development process, it’s continually validated against other changes happening concurrently in the shared repository.
Here is a simple continuous integration pipeline diagram:
If all jobs in a stage succeed, the pipeline moves on to the next stage.
If any job in a stage fails, the pipeline (usually) ends early before it proceeds to the next stage. Continuous integration pipeline activities can be customized to meet your unique needs.
A continuous integration pipeline improves code quality by ensuring that all code changes go through the same process. Code changes are validated against other changes being committed to the same shared code repository. Automated tests and builds decrease the chance of human error, creating faster iterations and better quality code.