What is Continuous integration (CI) and continuous delivery (CD) ?

Shivam Kumar

5 February 2020

Continuous integration (CI) and continuous delivery (CD) are extremely common terms used when talking about producing software. But what do they really mean? In this article, I’ll explain the meaning and significance behind these and related terms, such as continuous testing and continuous deployment.

What is continuous integration?

Continuous integration (CI) is the process of automatically detecting, pulling, building, and (in most cases) doing unit testing as source code is changed for a product. CI is the activity that starts the pipeline (although certain pre-validations—often called “pre-flight checks”—are sometimes incorporated ahead of CI).

The goal of CI is to quickly make sure a new change from a developer is “good” and suitable for further use in the code base.

How does continuous integration work?

The basic idea is having an automated process “watching” one or more source code repositories for changes. When a change is pushed to the repositories, the watching process detects the change, pulls down a copy, builds it, and runs any associated unit tests.

Gitlab CI

This should stay in your .gitlab-ci.yml inside your root project. Next time you’ll push your app to the branch, check the CI/CD from the left menu in your repository. A new pipeline should start.

<span id="3d82" class="ji iq ef at jj b fi jk jl r jm" data-selectable-paragraph="">stages:
  - test</span><span id="4aec" class="ji iq ef at jj b fi kb kc kd ke kf jl r jm" data-selectable-paragraph=""># Set up cache, so we have to run composer update between builds, speeding it up!
cache:
  key: ${CI_COMMIT_REF_SLUG}
  paths:
    - node_modules/
    - vendor/</span><span id="085a" class="ji iq ef at jj b fi kb kc kd ke kf jl r jm" data-selectable-paragraph="">test:
  image: edbizarro/gitlab-ci-pipeline-php:7.2
  stage: test
  services:
    - mariadb:10.3.11</span><span id="17f2" class="ji iq ef at jj b fi kb kc kd ke kf jl r jm" data-selectable-paragraph="">variables:
    MYSQL_DATABASE: "test"
    MYSQL_ROOT_PASSWORD: "secret"</span><span id="af40" class="ji iq ef at jj b fi kb kc kd ke kf jl r jm" data-selectable-paragraph="">script:
    - composer update --no-interaction --no-progress  --prefer-dist --optimize-autoloader --ignore-platform-reqs
    - cp .env.testing .env
    - php artisan key:generate
    - php artisan config:cache
    - php artisan route:cache
    - npm install
    - npm run prod
    - php artisan migrate --seed
    - php artisan storage:link
    - php artisan serve &amp;
    - vendor/bin/phpunit</span>

stages:

- test# Set up cache, so we have to run composer update between builds, speeding it up!

cache:

key: ${CI_COMMIT_REF_SLUG}

paths:

- node_modules/

- vendor/test:

image: edbizarro/gitlab-ci-pipeline-php:7.2

stage: test

services:

- mariadb:10.3.11variables:

MYSQL_DATABASE: "test"

MYSQL_ROOT_PASSWORD: "secret"script:

- composer update --no-interaction --no-progress --prefer-dist --optimize-autoloader --ignore-platform-reqs

- cp .env.testing .env

- php artisan key:generate

- php artisan config:cache

- php artisan route:cache

- npm install

- npm run prod

- php artisan migrate --seed

- php artisan storage:link

- php artisan serve &

- vendor/bin/phpunit

So, Gitlab CI relies on containers, so in case you want MySQL instead of MariaDB, feel free to change it to mysql:[your_version], for example: mysql:5.7. Also, if you don’t compile assets with npm, it’s useless to install and run prod.

What are the benefits of each practice?

We’ve explained the difference between continuous integration, continuous delivery, and continuous deployments but we haven’t yet looked into the reasons why you would adopt them. There’s an obvious cost to implementing each practice, but it’s largely outweighed by their benefits.

What is continuous deployment?

Continuous deployment (CD) generally refers to the overall chain of processes (pipeline) that automatically gets source code changes and runs them through build, test, packaging, and related operations to produce a deploy-able release, largely without any human intervention.

The goals of CD in producing software releases are automation, efficiency, reliability, re-productivity, and verification of quality (through continuous testing).

CD incorporates CI (automatically detecting source code changes, executing build processes for the changes, and running unit tests to validate), continuous testing (running various kinds of tests on the code to gain successive levels of confidence in the quality of the code), and (optionally) continuous deployment (making releases from the pipeline automatically available to users).

What are the benefits of Continuous deployment ?

Deployment is the final step of the overall ‘continuous pipeline’ that consists of integration, delivery, and deployment. The true experience of continuous deployment is automation to the level at which code is deployed to production, tested for correctness, and automatically reverted when wrong, or accepted if correct.

Conclusion

The goal of the continuous integration and continuous delivery (CI/CD) pipeline is to enable teams to release a constant flow of software updates into production to quicken release cycles, lower costs, and reduce the risks associated with development.