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.
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.
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.
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!
- 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:
- 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_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 &
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
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.
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).
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.
Be the first to comment.