Close

Intégration continue, livraison continue et déploiement continu

Découvrez les différences entre ces pratiques continues

Sten Pittet headshot
Sten Pittet

Contributing Writer


CI et CD sont deux acronymes fréquemment utilisés dans les pratiques modernes de développement et DevOps. CI désigne l'intégration continue, une bonne pratique DevOps fondamentale dans laquelle les développeurs mergent fréquemment les changements de code dans un dépôt central où des builds et des tests automatisés s'exécutent. L'acronyme CD peut, en revanche, désigner la « livraison continue » ou le « déploiement continu ».

Quelles sont les différences entre intégration continue, livraison continue et déploiement continu (CI/CD) ?


Continuous integration

Developers practicing continuous integration merge their changes back to the main branch as often as possible. The developer's changes are validated by creating a build and running automated tests against the build. By doing so, you avoid integration challenges that can happen when waiting for release day to merge changes into the release branch.

Continuous integration puts a great emphasis on testing automation to check that the application is not broken whenever new commits are integrated into the main branch.

Continuous delivery

Continuous delivery is an extension of continuous integration since it automatically deploys all code changes to a testing and/or production environment after the build stage.

This means that on top of automated testing, you have an automated release process and you can deploy your application any time by clicking a button.

In theory, with continuous delivery, you can decide to release daily, weekly, fortnightly, or whatever suits your business requirements. However, if you truly want to get the benefits of continuous delivery, you should deploy to production as early as possible to make sure that you release small batches that are easy to troubleshoot in case of a problem.

Découvrir la solution

Développez et exploitez des logiciels grâce à Open DevOps

Related material

What is the DevOps pipeline?

Continuous deployment

Comment ces pratiques sont-elles liées entre elles ?


En d'autres termes, l'intégration continue relève à la fois de la livraison continue et du déploiement continu. D'autre part, le déploiement continu est semblable à la livraison continue, à l'exception du fait que les versions sont créées automatiquement.

Differences between continuous integration, continuous delivery, and continuous deployment

Quels sont les avantages de chaque pratique ?


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.

Continuous integration

What you need (cost)

  • Your team will need to write automated tests for each new feature, improvement or bug fix.
  • You need a continuous integration server that can monitor the main repository and run the tests automatically for every new commits pushed.
  • Developers need to merge their changes as often as possible, at least once a day.

What you gain

  • Less bugs get shipped to production as regressions are captured early by the automated tests.
  • Building the release is easy as all integration issues have been solved early.
  • Less context switching as developers are alerted as soon as they break the build and can work on fixing it before they move to another task.
  • Testing costs are reduced drastically – your CI server can run hundreds of tests in the matter of seconds.
  • Votre équipe de QA passe moins de temps à tester et peut se concentrer sur d'importantes améliorations de la culture de la qualité.

Continuous delivery

What you need (cost)

  • You need a strong foundation in continuous integration and your test suite needs to cover enough of your codebase.
  • Deployments need to be automated. The trigger is still manual but once a deployment is started there shouldn't be a need for human intervention.
  • Your team will most likely need to embrace feature flags so that incomplete features do not affect customers in production.

What you gain

  • The complexity of deploying software has been taken away. Your team doesn't have to spend days preparing for a release anymore.
  • You can release more often, thus accelerating the feedback loop with your customers.
  • There is much less pressure on decisions for small changes, hence encouraging iterating faster.

Continuous deployment

What you need (cost)

  • Your testing culture needs to be at its best. The quality of your test suite will determine the quality of your releases.
  • Your documentation process will need to keep up with the pace of deployments.
  • Les feature flags deviennent une partie intégrante du processus de livraison de changements importants afin de vous assurer la coordination avec d'autres services (support, marketing, relations publiques…).

What you gain

  • You can develop faster as there's no need to pause development for releases. Deployments pipelines are triggered automatically for every change.
  • Releases are less risky and easier to fix in case of problem as you deploy small batches of changes.
  • Customers see a continuous stream of improvements, and quality increases every day, instead of every month, quarter or year.

One of the traditional cost associated with continuous integration is the installation and maintenance of a CI server. But you can reduce significantly the cost of adopting these practices by using a cloud service like Bitbucket Pipelines which adds automation to every Bitbucket repository. By simply adding a configuration file at the root of your repository you will be able to create a continuous deployment pipeline that gets executed for every new change pushed to the main branch.

A continuous deployment pipeline with Bitbucket

Going from continuous integration to continuous deployment


Si vous démarrez sur un nouveau projet sans aucun utilisateur, il peut être facile pour vous de déployer chaque commit en production. Vous pourriez même commencer par automatiser vos déploiements et livrer votre version alpha dans un environnement de production sans clients. Ensuite, vous pourriez intensifier votre culture en matière de tests et veiller à augmenter la couverture de code au fur et à mesure que vous développez votre app. Lorsque vous serez prêt à intégrer les utilisateurs, vous aurez un excellent processus de déploiement continu où tous les nouveaux changements seront testés avant d'être automatiquement livrés en production.

Mais si vous disposez déjà d'une app existante avec des clients, il est préférable d'y aller en douceur et de commencer par l'intégration continue et la livraison continue. Commencez par implémenter des tests d'unités de base dont l'exécution est automatique ; il n'est pas encore nécessaire de vous concentrer sur l'exécution de tests complexes de bout en bout. Essayez plutôt d'automatiser vos déploiements dès que possible et d'atteindre un stade où les déploiements vers vos environnements de staging sont effectués automatiquement. En effet, si vous avez des déploiements automatiques, vous pouvez concentrer votre énergie sur l'amélioration de vos tests au lieu d'interrompre périodiquement votre travail pour coordonner une livraison.

Lorsque vous commencerez à livrer des logiciels de façon quotidienne, vous pourrez vous intéresser au déploiement continu. Assurez-vous cependant que le reste de votre organisation est également prêt. Vos équipes de documentation, de support ou encore marketing devront s'adapter au nouveau rythme de livraison, et il est important qu'elles ne passent pas à côté de changements importants susceptibles d'affecter des clients.

Nos guides


Read our guides

You can find some guides that will go more in depth to help you getting started with these practices.

Sten Pittet
Sten Pittet

Cela fait maintenant dix ans que je travaille dans le secteur logiciel et j'ai occupé différentes fonctions, du développement à la gestion de produits. Après avoir passé les cinq dernières années chez Atlassian à travailler sur des outils de développement, j'écris désormais des articles sur le développement des logiciels. En dehors de mon travail, j'affine mes compétences de père au contact d'un adorable bébé.


Share this article

Recommended reading

Bookmark these resources to learn about types of DevOps teams, or for ongoing updates about DevOps at Atlassian.

Devops illustration

DevOps community

Devops illustration

Lire le blog

Map illustration

Get started for free

Sign up for our DevOps newsletter

Thank you for signing up