Gestion des pipelines de déploiement

Un pipeline de déploiement contient les exigences qui doivent être satisfaites pour fournir un jeu d'artefacts à l'environnement cible.

Les pipelines de déploiement contiennent différentes étapes pour le déploiement automatisé. Chaque étape est associée à certaines actions du pipeline. Vous pouvez exécuter le pipeline de déploiement à l'aide de l'une des stratégies de lancement suivantes :

  • Stratégie bleu/vert : Implique l'exécution de deux environnements de production identiques, un bleu et un vert, pour limiter les temps d'arrêt et les risques. Un seul environnement est actif à un moment donné et exécute le trafic de production. Par exemple, si l'environnement bleu est actif (environnement de production), le vert est l'environnement de secours (environnement intermédiaire), et inversement. Les environnements bleu et vert sont actifs tour à tour lors des déploiements successifs. Lors du déploiement d'une nouvelle version de l'application, le test de la nouvelle version est effectué dans l'environnement de secours (vert). Si le test réussit, le trafic passe de l'environnement actif (bleu) à l'environnement de secours. La version validée du logiciel est déployée avec succès, l'environnement vert devient actif et le bleu est l'environnement de secours. La stratégie de déploiement bleu/vert réduit considérablement les temps d'arrêt dans un modèle de livraison continue, car la validation des nouvelles versions est effectuée dans des environnements de secours sans incidence sur l'environnement de production courant. En outre, cette stratégie réduit le risque de défaillance pendant le déploiement, car vous pouvez revenir à la version précédente ayant réussi, simplement en déplaçant le trafic de production.
  • Stratégie de test canari : Permet de lancer initialement la nouvelle version du logiciel dans l'environnement de test canari. Une fois cette version validée, le logiciel est lancé dans l'environnement de production. Cette stratégie, comme la stratégie bleu/vert, réduit les temps d'arrêt et les risques liés au déploiement. Si la version initiale échoue, cela n'a pas d'incidence sur l'environnement de production. Seules les versions réussies et approuvées sont poussées en production.
  • Stratégie continue : Une nouvelle version est déployée de manière incrémentielle dans l'environnement cible en mettant à jour un ensemble d'hôtes à la fois. La mise à jour est validée avant que l'ensemble d'hôtes suivant soit mis à jour. Ce processus est répété jusqu'à ce que le déploiement de la nouvelle version soit terminé.

Les artefacts peuvent être mutables ou non mutables. Dans le registre d'artefacts, vous pouvez remplacer un artefact mutable. Pour ce faire, chargez un artefact dans un référentiel mutable et affectez-lui le nom d'un artefact supprimé ou, s'il existe un artefact portant le même nom, le nouvel artefact supprime et remplace l'ancien. Le pipeline de déploiement DevOps extrait les artefacts en fonction du chemin et de la version des artefacts. Pour les artefacts mutables, il peut s'agir du dernier artefact trouvé dans le référentiel.

Une étape est une action dans le pipeline de déploiement. Le service DevOps comprend des étapes prédéfinies, qui sont prêtes à être utilisées dans un pipeline de déploiement. Ces étapes sont les suivantes :

Vous pouvez ajouter plusieurs étapes à un pipeline. Les étapes peuvent être ajoutées en séquence ou en parallèle. Vous pouvez supprimer une étape quelconque du pipeline. Dans ce cas, l'étape et les ressources associées sont supprimées.