L’intégration continue
L’intégration continue consiste à effectuer un ensemble d’opération au moment où l’en envoie du code vers le dépôt. C’est-à-dire au moment d’un git push. Ces opérations peuvent être :
- Exécuter des tests unitaires.
- Exécuter un outils de vérification des normes de développement (conventions de nommage, indentation, etc.).
- Exécuter des règles d’audit sécurité.
- Exécuter une commande pour que les bibliothèques externes soient mises à jour via Composer.
- Etc.
Cela rallonge inévitablement le temps des git push, mais cela permet de s’assurer que ce qu’on envoie sur le dépôt du projet est le plus fiable et stable possible.
Pour cela, le logiciel qui gère le dépôt doit être configuré afin d’exécuter automatiquement ce qu’on nomme des pipelines. Le logiciel peut être GitHub, GitLab, ou autre, et c’est lui, côté serveur, qui exécutera les différentes étapes d’une ou plusieurs pipelines, dans l’ordre qui aura été défini.
Les pipelines peuvent être bloquantes et avoir pour effet de rejeter du code.
Le déploiement continue
Le déploiement continue consiste à ce qu’un code ayant été poussé vers un dépôt et pour lequel les pipelines de l’intégration continue ont été automatiquement exécutées et validées, soit ensuite automatiquement poussé vers la branche principale du projet.
En opposition, on parle de livraison continue (dont les initiales sont également CD pour Continuous Delivery) lorsqu’une intervention manuelle a lieu pour effectuer un merge vers la branche principale du projet.ipeline changer de statut pour “passed”.
Le comportement par défaut est alors un push habituel vers votre branche principale master et mettre à jour votre dépôt.
C’est ce qu’on nomme le déploiement continu parce qu’il ne nécessite pas d’autre action de votre part.
La livraison continue (dont les initiales sont aussi CD pour Continuous Delivery) part du même principe sauf que vous devez manuellement valider la mise à jour du dépôt par un “merge”.