Skip to content
Knowledge Hub/Article
Article

What Is CI/CD? Continuous Integration, Delivery and Jenkins

We explain continuous integration, delivery and deployment, pipeline stages, Jenkins and other tools, deployment strategies and pipeline security.

Oğuzhan Gerçek··10 min read
What Is CI/CD? Continuous Integration, Delivery and Jenkins

Short answer: CI/CD is the set of practices that automatically builds, tests and moves software changes to production. CI (continuous integration) means everyone merges their code into a shared main branch at least once a day, and every merge is verified by an automated build and tests. CD stands for continuous delivery or continuous deployment: with the first, the final step to production is taken after an approval; with the second, every change that passes the tests goes to production on its own. A pipeline defined in a tool such as Jenkins, GitHub Actions or GitLab CI/CD runs these steps, and because it has access to secrets, the pipeline itself needs protecting.

What is CI/CD?

As GitLab defines it, CI/CD is a continuous method of software development in which iterative code changes are continuously built, tested, deployed and monitored. What "CD" stands for depends on the source: GitHub expands it as continuous delivery, while NIST's SP 800-204D expands it as continuous deployment. We cover where CI/CD sits within DevOps and how to measure it with DORA's metrics in our DevOps article.

Continuous integration (CI) and the role of automated testing

According to Martin Fowler's article Continuous Integration (last updated January 18, 2024), in CI each member of a team merges their changes into the codebase at least daily, and each integration is verified by an automated build, including tests, to detect integration errors as quickly as possible. According to Fowler, Kent Beck developed the practice in the 1990s as part of Extreme Programming (XP). The practices he lists include triggering a build on every push, fixing broken builds right away and keeping the build fast; for most projects, he considers XP's ten-minute build guideline perfectly within reason. DORA also recommends merging into trunk at least daily rather than working on long-lived feature branches (Git article).

CI is only as good as its tests. DORA wants developers to get feedback from automated tests in less than ten minutes and says not to tolerate flaky tests; it calls manual regression testing a bottleneck.

Continuous delivery vs. continuous deployment

Fowler's Continuous Delivery post (May 30, 2013) defines continuous delivery as building software so that it can be released to production at any time: you are able to deploy frequently but may choose not to. With continuous deployment, every change goes through the pipeline and automatically gets put into production. According to AWS, what separates the two is the presence of a manual approval before production.

In GitHub Actions, required reviewers configured on an environment make jobs that reference that environment wait for approval from a specific person or team, and a job cannot access the environment's secrets until it is approved. In GitLab, a job defined with when: manual does not run until a user starts it; the documentation suggests it for jobs such as deploying to production.

CI/CD pipeline stages

  1. Trigger: A push or merge to the main branch starts the pipeline.
  2. Build: The code is compiled and packaged; if containers are used, an image is built (Docker article).
  3. Test: Unit tests come first, followed by broader tests such as the UI, load, integration and API reliability testing that AWS lists.
  4. Security scanning: According to GitLab, static application security testing (SAST) discovers vulnerabilities in source code before they reach production.
  5. Artifact: In GitLab's terms, the archive of files and directories a job outputs is a job artifact; this is the package that gets deployed.
  6. Deploy: The package goes to a test system first, then to production, either after an approval or automatically.

In the .gitlab-ci.yml example below, the deploy job is started manually; because stages is not defined, GitLab uses the default stages (.pre, build, test, deploy, .post):

build:
  stage: build
  script: [make build]
test:
  stage: test
  script: [make test]
deploy:
  stage: deploy
  script: [./deploy.sh production]
  when: manual

What is Jenkins?

According to its documentation, Jenkins is a self-contained, open-source automation server that automates tasks related to building, testing and delivering or deploying software. It can be installed through native system packages or Docker, or run standalone on any machine with a Java Runtime Environment (JRE). Its capabilities are extended through plugins; the project's site lists more than 2,300 community-contributed plugins.

Its main feature is Pipeline: a pipeline is defined in code in a text file called a Jenkinsfile, which is committed to the project's repository. There are two syntaxes: Declarative, designed to make writing and reading Pipeline code easier, and Scripted, built around node blocks.

The project used to be called Hudson. According to a January 11, 2011 post on the Jenkins blog, after Oracle filed trademark applications for the Hudson name, the project team proposed Jenkins as the new name; in the vote announced on January 29, 2011, the rename passed 214 to 14. Alongside weekly releases, there is an LTS line for which a new baseline is picked every 12 weeks.

The Jenkins documentation recommends running builds on agents rather than on the controller's built-in node, because builds on the built-in node have the same level of access to the controller file system as the Jenkins process.

GitHub Actions, GitLab CI/CD and Azure Pipelines

  • GitHub Actions: GitHub's CI/CD platform. Workflows are defined in YAML files in the repository's .github/workflows directory and run on runners provided by GitHub or hosted by you.
  • GitLab CI/CD: The pipeline is built from stages and jobs in a .gitlab-ci.yml file at the root of the project; jobs are run by GitLab.com's ready-made runners or by runners you register yourself.
  • Azure Pipelines: According to Microsoft, the part of Azure DevOps that combines continuous integration, continuous testing and continuous delivery.

Deployment strategies: blue-green, canary and rolling

  • Blue-green: As Fowler describes it, you keep two production environments, as identical as possible; the router is switched to the one running the new version and switched back if anything goes wrong (load balancer article). Databases can often be a challenge with this technique.
  • Canary: According to Danilo Sato's 2014 post, the new version is rolled out to a small subset of users first; rolling back simply means rerouting users to the old version.
  • Rolling: According to AWS, previous versions are replaced step by step with the new one; it completes more quickly, but there is no environment isolation between the old and new versions, and rollback becomes harder (Kubernetes article).

With GitOps, the pipeline does not push the deployment: under the OpenGitOps principles (v1.0.0), desired state is expressed declaratively, as with IaC, and stored with versioning; software agents pull it from the source and continuously reconcile the system toward it (Git article).

Pipeline security: OWASP, SLSA and NIST

OWASP's Top 10 CI/CD Security Risks helps defenders identify focus areas; the ten risks include Poisoned Pipeline Execution, insufficient credential hygiene and improper artifact integrity validation. OWASP recommends that pipelines running unreviewed code run on isolated nodes that are not exposed to secrets.

According to GitHub's advisory, in March 2025 a supply chain attack compromised the tj-actions/changed-files action, impacting more than 23,000 repositories: attackers retroactively pointed version tags to a malicious commit, secrets were exposed in workflow logs, and the advisory calls for rotating those secrets immediately. GitHub's secure use reference recommends locking workflow dependencies with a lockfile and, where that is not possible, pinning actions to a commit SHA; a tag can be moved by anyone who gains access to the repository.

SLSA (Supply-chain Levels for Software Artifacts), part of the OpenSSF, is a checklist of standards and controls to prevent tampering and improve integrity. In the approved version 1.2, the build levels start with provenance (L1) and move up to a hosted platform that signs the provenance (L2) and hardened builds (L3). NIST's SP 800-204D, published in February 2024, sets two broad goals: actively defending the CI/CD pipeline and build processes, and ensuring the integrity of upstream sources and artifacts.

Managing secrets

  • Keep them out of code: According to GitHub, sensitive data should never be stored as plaintext in workflow files; GitLab also wants tokens and passwords kept in the UI settings, not in .gitlab-ci.yml (Git article).
  • Narrow the scope: GitLab's protected variables are available only to pipelines that run on protected branches or tags; GitHub recommends granting the GITHUB_TOKEN the minimum required permissions (IAM article).
  • Use short-lived credentials: OWASP recommends temporary credentials over static ones, and GitHub recommends short-lived tokens created with OpenID Connect.
  • Don't rely on masking: According to GitLab, masking a variable is not a guaranteed way to prevent malicious users from accessing its value (log article).

We handle pipeline setup and secret management in our DevOps & CI/CD Enablement service, standard templates in DevOps & platform engineering, and day-to-day operations in DevOps solutions.

Frequently asked questions

What is Jenkins used for? It is an open-source automation server that automates building, testing and deploying software. Pipelines can be defined in a Jenkinsfile committed to the repository.

What does CI/CD stand for? Continuous integration and continuous delivery (or deployment). It describes moving code changes to production through automated builds, tests and deployments.

What is continuous integration? A practice in which everyone merges their changes into a shared main branch at least once a day, and every merge is verified by an automated build and tests.

What is the difference between continuous delivery and continuous deployment? In continuous delivery, the final step to production is taken after an approval. In continuous deployment, every change that passes the tests goes to production automatically.

Sources