Qu'est-ce que l'intégration continue et la livraison/le déploiement continus ?
Cette section traite des pratiques d'intégration continue et de livraison continue et explique la différence entre la livraison continue et le déploiement continu.
Intégration continue
L'intégration continue (CI) est une pratique de développement logiciel selon laquelle les développeurs fusionnent régulièrement leurs modifications de code dans un référentiel central, après quoi des générations et des tests automatisés sont exécutés. La CI renvoie habituellement à la phase de génération ou d'intégration du processus de lancement de logiciels et implique une composante d'automatisation (par exemple, une CI ou un service de génération) et une composante culturelle (par exemple, apprendre à intégrer fréquemment). Les principaux objectifs de l'intégration continue sont les suivants : trouver et corriger plus rapidement les bogues, améliorer la qualité des logiciels et réduire le temps nécessaire pour valider et publier de nouvelles mises à jour de logiciels.
L'intégration continue se concentre sur des validations et des modifications de plus petites portions du code à intégrer. Un développeur valide le code à intervalles réguliers, au moins une fois par jour. Il extrait le code du référentiel de code pour s'assurer que le code sur l'hôte local est fusionné avant de le transmettre au serveur de développement. À ce stade, le serveur de développement exécute les différents tests et accepte ou rejette le code validé.
Les principales difficultés de la mise en œuvre de l'intégration continue incluent des validations plus fréquentes dans la base de code commune, la gestion d'un référentiel de code source unique, ainsi que l'automatisation des générations et des tests. Parmi les autres difficultés, citons les tests dans des environnements similaires à ceux de la production, la visibilité du processus pour l'équipe et la possibilité pour les développeurs d'obtenir facilement n'importe quelle version de l'application.
Livraison et déploiement continus
La livraison continue (CD) est une méthode de développement de logiciels selon laquelle les changements de code sont automatiquement générés, testés et préparés pour une publication dans un environnement de production. Elle est le prolongement de l'intégration continue à travers le déploiement de toutes les modifications de code dans un environnement de test et/ou de production, une fois la phase de génération terminée. La livraison continue peut être entièrement automatisée au moyen d'un processus de flux ou partiellement automatisée avec des étapes manuelles aux points critiques. Une livraison continue correctement mise en œuvre permet aux développeurs de toujours disposer d'un artefact de génération prêt au déploiement ayant suivi un processus de test standardisé.
Grâce au déploiement continu, les révisions sont déployées automatiquement dans un environnement de production, sans nécessiter d'approbation explicite de la part d'un développeur. Le processus de lancement de logiciels est alors entièrement automatisé. Ainsi, il est possible de créer une boucle de rétroaction continue des clients dès le début du cycle de vie du produit.
La livraison continue n'est pas un déploiement continu
Une idée fausse concernant la livraison continue consiste à considérer que chaque modification validée est appliquée à la production immédiatement après avoir réussi les tests automatisés. En réalité, la livraison continue n'a pas pour objectif d'appliquer immédiatement chaque modification à la production, mais bien de s'assurer que chaque modification peut être mise en production.
Avant de déployer une modification dans un environnement de production, vous pouvez mettre en œuvre un processus décisionnel afin de vous assurer que le déploiement en production est autorisé et audité. Cette décision peut être prise par une personne, puis exécutée par les outils.
En utilisant la livraison continue, la décision de mise en service devient une décision commerciale et non technique. La validation technique a lieu à chaque validation.
Le déploiement d'une modification en production n'est pas un événement perturbateur. Il n'oblige pas l'équipe technique à arrêter de travailler sur la prochaine série de modifications. En outre, il n'est pas nécessaire de préparer un plan de projet, une documentation de transfert ou un créneau de maintenance. Le déploiement devient un processus reproductible qui a été réalisé et éprouvé à de nombreuses reprises dans des environnements de test.
