Gestion des pipelines de déploiement

Un pipeline de déploiement contient les exigences à satisfaire pour distribuer un ensemble d'artefacts à l'environnement cible.

Les pipelines de déploiement contiennent différentes phases pour le déploiement automatisé. Chaque phase est associée à certaines actions dans le pipeline. Vous pouvez exécuter le pipeline de déploiement en fonction de l'une des stratégies de publication suivantes :

• Stratégie bleu/vert : implique l'exécution de deux environnements de production identiques, un bleu et un vert, pour réduire les temps d'arrêt et les risques. Seul un des environnements est actif à tout moment, l'environnement actif exécutant le trafic de production. Par exemple, si le bleu est actif (environnement de production), le vert est celui de secours (environnement de préparation) et inversement. L'environnement actif alterne entre l'environnement bleu et le vert lors de 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 alors actif et le bleu devient celui de secours. La stratégie de déploiement bleu/vert réduit considérablement les temps d'arrêt dans un modèle de prestation continue car la validation des nouvelles versions s'effectue dans les environnements de secours, sans incidence sur l'environnement de production actuel. De plus, cette stratégie réduit les risques d'échec de déploiement car il est possible d'annuler ce dernier et de revenir à la version précédente ayant réussi simplement en déplaçant le trafic de production.
• Stratégie canari : permet de publier initialement la nouvelle version du logiciel dans l'environnement canari. Une fois la version validée, le logiciel est publié vers 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 publication initiale échoue, cela n'a aucune incidence sur l'environnement de production. Seules les versions ayant réussi et approuvées sont transmises à l'environnement de production.
• Stratégie non simultanée : une nouvelle version est déployée de manière incrémentielle vers l'environnement cible en mettant à jour un ensemble d'hôtes à la fois. Cette mise à jour est validée avant la mise à jour de l'ensemble d'hôtes suivant. 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 référentiel Artifact Registry, vous pouvez remplacer un artefact mutable. Pour ce faire, téléchargez un artefact vers un référentiel mutable et affectez-lui le nom d'un artefact supprimé, ou si un artefact du même nom existe, 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 d'artefact. Pour les artefacts mutables, il peut s'agir du dernier artefact trouvé dans le référentiel.

Une phase est une action dans le pipeline de déploiement. Le service DevOps inclut des phases prédéfinies, qui peuvent être facilement utilisées dans un pipeline de déploiement. Ces phases prédéfinies sont les suivantes :

• Déploiement vers un cluster Kubernetes : utilise la stratégie de mise à jour non simultanée Kubernetes intégrée.
• Déploiement vers un groupe d'instances : mise à jour de version (release) de façon incrémentielle vers le groupe d'instances. Vous pouvez indiquer le nombre maximal d'instances pouvant être hors ligne en même temps. Ce type de phase prend en charge les annulations automatiques.
• Déploiement à l'aide de la stratégie bleu/vert : utilise une stratégie de publication bleu/vert pour le déploiement de Container Engine for Kubernetes (OKE) et de groupe d'instances.
• Déploiement à l'aide de la stratégie de canari : utilise la stratégie de publication canari pour le déploiement OKE et de groupe d'instances.
• Déploiement vers Functions : utilise la stratégie de mise à jour Functions intégrée.
• Déploiement d'un chart Helm : installez des charts Helm dans un cluster OKE.
• Contrôle :
  • Approbation : met le déploiement en pause et attend une décision manuelle.
  • Changement de trafic : achemine le trafic entre deux environnements.
  • Attente : met en pause le déploiement pendant une durée donnée.
• Intégrations :
  • Appeler une fonction : appelle une fonction pour exécuter une logique personnalisée.
  • Shell : exécutez des étapes personnalisées définies dans la spécification de commande dans le pipeline de déploiement.

Vous pouvez ajouter plusieurs phases à un pipeline. Les phases peuvent être ajoutées de manière séquentielle ou en parallèle. Vous pouvez enlever des phases du pipeline. Dans ce cas, la phase et les ressources qui lui sont associées sont supprimées.