Let's talk about continuous integration and continuous deployment (CI / CD)

Just like Github or Docker, most of today's developers have come across this strange collection of letters.

Well, today we're going to tell you what it means, what it is and what it's for!

Continuous Integration(CI) and Continuous Deployment(CD) are steps in the versioning of your code. In fact, if you'd like us to explain versioning, Git and all that follows in another article, don't hesitate to let us know!

Continuous integration

This stage consists of carrying out a battery of tests when you send your code to your repository to check that everything is in order on a number of points. This can be a security audit of your project's dependencies, a quick check of your code's writing and best practices, or unit/functional tests.

"But that's all very well, but will it make my git push take longer?!"

Well, yes. But no. Just as writing your unit and functional tests takes you time at the time. It saves you a lot of time later on, when it comes to finding out if there's something wrong with the code. And, incidentally, you won't break everything if you make a push in production.

What's more, your push itself will take just as long as before, since the tests will be carried out directly on your server-side repository, not in your console.

The advantage of running an entire process at repository time is that it will be done automatically by your tool (Github, Gitlab, etc.) via what are known as pipelines.

These will run in an order defined by you, with or without blocking steps (depending on your choice).

For example, let's imagine that in a Symfony project, you want to check before each deployment that the dependencies used in your project by Composer are up to date and without security holes.

In this case, you can use a tool such as local-php-security-checker, available here in a Docker image designed for CI/CD.

"Okay, but where do I run this tool and how do I set up all the scripts that are going to be launched each time I prod?"

Thanks to a simple file called .gitlab-ci.yml (in the case of Gitlab) in which you define the name of each stage, as well as the order and whether or not it will be blocked in the event of failure.

If you add this little file to the root of your Symfony project, it will automatically create a Pipeline on Gitlab for your next push, which will launch all the necessary tests before validating your push.

Continuous deployment

Once your internships have passed without a hitch, you'll see your Pipeline status change to "passed".

The default behavior is then the usual push to your main master branch and update your repository.
This is called continuous deployment because it requires no further action on your part.
Continuous Delivery (whose initials are also CD) is based on the same principle, except that you must manually validate the repository update with a merge.

You'll find all the details on the Gitlab interface (you can even follow the process in real time!).

And in the event of success or failure, you'll get an email to let you know. Isn't that nice?