Organigramme du processus de déploiement de logiciels : de la conception à la…
Un organigramme du processus de déploiement de logiciels : créer et versionner l'artefact, contrôle de qualité, promotion du registre, vérifications intermédiaires, déploiement Canari, restauration automatique.
Qu'est-ce que le processus organigramme du processus de déploiement de logiciels : de la conception à la… ?
Un processus de déploiement de logiciel est le mécanisme permettant d'obtenir un artefact de construction sur une infrastructure en cours d'exécution. Cela commence par une fusion et se termine soit par une version entièrement déployée, soit par un retour à la précédente. Cela le rend délibérément plus restreint que la gestion des versions, qui décide de ce qui appartient à une version, du moment où la portée se fige et si l'organisation est prête à la livrer. La gestion des versions répond si et quoi ; le déploiement répond comment. Si le diagramme dont vous avez besoin contient un gel de la portée, une approbation UAT et une réunion go/no-go, vous souhaitez le processus de publication. S'il contient une version d'artefact, un registre, un changement de trafic et un déclencheur de restauration, vous êtes au bon endroit. Il ne s'agit pas non plus de gestion des changements informatiques : la fenêtre de changement et l'approbation qui l'ouvre apparaissent ici comme deux étapes, et non comme un sujet, car ce graphique suppose qu'un chemin d'approbation existe déjà et montre où l'attend le déploiement.
La plupart des incidents de déploiement remontent à un petit nombre d'hypothèses non retenues. L'artefact est reconstruit par environnement, donc ce qui a réussi les tests n'est pas tout à fait ce qui a atteint la production. La mise en scène s'est éloignée de la configuration de production il y a des mois, donc une fumée verte s'avère moins que ce que les gens pensent. Le déploiement n'a pas de taille d'étape ni de temps de cuisson définis, donc tout le trafic se déplace en même temps et le premier signe de problème est la file d'attente d'assistance. Et le déclencheur de restauration est une personne qui regarde un tableau de bord plutôt qu'un seuil que le pipeline peut évaluer lui-même, ce qui transforme une restauration rapide et ennuyeuse en débat. Dessiner le flux sous forme de couloirs montre clairement quelles étapes vous avez automatisées et lesquelles dépendent encore de la mémorisation de quelqu'un.
Ce modèle est un flux de déploiement fonctionnel sur cinq voies, développeur, pipeline CI/CD, assurance qualité, ingénieur de publication et opérations, réparti en cinq phases, de la construction au déploiement en production. Il dessine les trois boucles qui ne sont généralement pas documentées : le contrôle de qualité qui renvoie une version défaillante au développeur au lieu de la laisser avancer, la vérification intermédiaire qui fait la même chose avant que quiconque ne réserve une fenêtre de modification, et la restauration automatique qui renvoie un déploiement violé à la même étape de correction des défauts. Il montre également la stratégie de déploiement comme une décision plutôt qu'une hypothèse, de sorte que le bleu-vert et le canari figurent sur la carte comme deux itinéraires nommés qui se rejoignent sur un chemin partagé de transfert de trafic et de contrôle de santé.
Ce que couvre cet organigramme
Dans ce modèle
- Construction et version sur les deux premières voies : un développeur fusionne avec la branche principale, puis le pipeline CI/CD construit l'artefact une fois et l'estampille avec le commit dont il provient, de sorte que chaque environnement ultérieur déploie ce même artefact.
- Le portail qualité : le pipeline exécute les tests et les analyses automatisés, puis l'assurance qualité possède le « Portail qualité réussi ? » décision, qui achemine un échec vers « Réparer le défaut et reconstruire » plutôt que d'aller de l'avant.
- Promotion et mise en scène en tant qu'étapes distinctes : l'artefact est promu dans le registre, déployé vers la mise en scène par le pipeline, puis vérifié par l'assurance qualité avec des tests de fumée et d'intégration avant l'étape « Mise en scène saine ? décision, dont la branche défaillante revient également à la réparation des défauts.
- Approbation avec un résultat vraiment négatif : l'ingénieur de publication demande une fenêtre de changement de production, les opérations effectuent le "Déploiement **approuvé ?**" appel, et un refus met fin à la tentative de « Déploiement retenu pour la fenêtre suivante » au lieu de continuer tranquillement.
- La stratégie de déploiement dessinée comme une décision : « Bleu-vert ou canari ? se divise en déploiement vers l'environnement inactif ou vers les instances Canari, et les deux branches se rejoignent lors de « Changer le trafic avec des contrôles de santé ».
- Annulation et achèvement dans la voie des opérations : un message « Budget d'erreur dépassé ? » La décision envoie un déploiement défaillant vers « Revenir à la version précédente » et revient à la correction des défauts, tandis qu'un déploiement sain termine le déploiement, le surveille et ferme l'enregistrement de déploiement.
Quand utiliser ce modèle
- Documenter comment une build atteint réellement la production pour une équipe dont les étapes de déploiement se trouvent dans un fichier de configuration de pipeline et dans la tête de quelques personnes.
- Acceptez le déclencheur de restauration avant d'en avoir besoin, de sorte que l'appel soit un seuil mesuré plutôt qu'un jugement porté sous pression au pire moment.
- Ingénieurs d'intégration, analystes assurance qualité et personnel de garde qui ont besoin de savoir quelle porte ils possèdent et ce qui se passe en aval lorsqu'ils la détiennent.
- Décider par service si vous déployez bleu-vert ou canari, et enregistrer ce choix là où les personnes exécutant le déploiement peuvent le voir.
- Répondre à la question d'un auditeur ou d'un client sur la manière dont un changement est testé, autorisé et annulé, parallèlement à votre procédure de gestion du changement.
Comment cela fonctionne
Renommez les voies selon vos vrais rôles
Remplacez le développeur, le pipeline CI/CD, l'assurance qualité, l'ingénieur de publication et les opérations par les rôles que vous avez réellement. De nombreuses équipes n'ont pas d'ingénieur de publication, auquel cas fusionnez cette voie avec celui qui possède la production plutôt que de laisser un groupe vide. Conservez le pipeline CI/CD comme sa propre voie même s'il s'agit d'automatisation, car le but du graphique est de montrer quelles étapes une machine effectue et lesquelles une personne exécute encore.
Dites ce qu'est l'artefact et où il vit
Notez le type d'artefact (image du conteneur, package, bundle), le schéma de version, comment la version est dérivée de la validation, quel registre la contient et combien de temps elle est conservée. Énoncez ensuite la règle dont dépend le reste du tableau : construire une seule fois et promouvoir le même artefact, ne jamais reconstruire par environnement. Si votre pipeline est en cours de reconstruction, marquez-le sur le diagramme, car cela rompt le lien entre ce qui a été testé et ce qui a été expédié.
Définir ce que chaque porte vérifie réellement
« Le portail de qualité est passé ? » est aussi utile que sa définition. Indiquez quelles suites de tests doivent être vertes, quelle tolérance de flocon ou de couverture vous acceptez, quelles analyses de sécurité et de dépendances bloquent la construction et qui peut remplacer un résultat rouge. Faites de même pour les contrôles de préparation et d'intégration, et répertoriez les différences connues entre la préparation et la production (volume de données, bacs à sable tiers, infrastructure réduite) afin que tout le monde sache ce qu'une exécution de préparation saine fait et ne prouve pas.
Corriger la fenêtre de modification et qui l'ouvre
Enregistrez quand les déploiements peuvent être exécutés, qui les approuve et ce qui arrive à un déploiement qui n'est pas approuvé. Notez si ce type de déploiement est pré-autorisé dans le cadre d'un modèle de changement permanent ou nécessite une approbation individuelle à chaque fois, et nommez la personne qui peut l'approuver en dehors des heures normales. Si un déploiement suspendu attend simplement la fenêtre suivante, indiquez combien de temps l'artefact reste valide avant de devoir être reconstruit et retesté.
Choisissez une stratégie par service et rédigez les étapes de déploiement
Choisissez bleu-vert ou canari pour chaque service et indiquez votre choix sur la carte. Ensuite, écrivez les mécanismes : les incréments de trafic, la durée pendant laquelle vous observez entre eux, les contrôles de santé exécutés à chaque étape et à quoi le canari est comparé. Gérez les modifications de la base de données séparément, car une migration de schéma est généralement la raison pour laquelle une restauration n'est pas simplement un retour en arrière ; la séparation des migrations d'extension et de contrat du déploiement de code permet de conserver l'ancienne version exécutable.
Rendre le déclencheur de restauration mesurable, puis publier le graphique
Remplacez « quelqu'un remarque » par un signal que le pipeline peut évaluer : taux d'erreur ou latence par rapport à l'objectif de niveau de service, sur une fenêtre d'observation indiquée, avec une action convenue. Répétez la restauration pour savoir combien de temps cela prend. Partagez ensuite le diagramme à côté du runbook, capturez l'approbation des personnes qui y sont nommées, conservez une version actuelle et examinez-la après tout déploiement qui s'est mal passé.
Questions fréquentes
Quelle est la différence entre un processus de déploiement et un processus de publication ?
Le processus de publication décide ce qui est expédié et s'il doit le faire : quels changements sont dans la portée, quand la portée se fige, qui approuve l'UAT et si l'appel go/no-go est oui. Le processus de déploiement est la mécanique sous-jacente : créer un artefact une fois, le versionner, le promouvoir, le vérifier lors de la préparation, le déplacer vers l'infrastructure de production et le restaurer s'il se comporte mal. La relation n’est pas individuelle. Une seule version peut impliquer plusieurs déploiements, et de nombreux déploiements se produisent sans aucune version attachée, par exemple lorsque le code est livré derrière un indicateur de fonctionnalité et est activé ultérieurement. Ce modèle couvre la mécanique ; si vous avez besoin d'un gel de la portée, d'une approbation UAT et d'une porte d'entrée/sortie, utilisez plutôt le modèle de processus de publication du logiciel.
Quelles sont les étapes d’un processus de déploiement de logiciel ?
Cinq étapes couvrent la plupart des équipes. Construction et version : fusionnez la modification, construisez l'artefact une fois à partir d'une extraction propre et tamponnez-le avec son commit. Tests et contrôle qualité : exécutez les tests et analyses automatisés et renvoyez les échecs au développeur plutôt que de les transmettre. Mise en scène : faites la promotion de l'artefact dans le registre, déployez-le dans la mise en scène et effectuez des contrôles de fumée et d'intégration. Approbation et fenêtre : demandez la fenêtre de changement de production et faites approuver le déploiement, ou conservez-le pour le suivant. Déploiement en production : déployez du bleu-vert ou du canari, déplacez le trafic par étapes avec des contrôles de santé, annulez automatiquement si le budget d'erreurs est dépassé, sinon terminez le déploiement, surveillez-le et fermez l'enregistrement de déploiement.
Faut-il déployer le bleu-vert ou le canari ?
Bleu-vert exécute deux environnements de production et bascule le trafic entre eux, de sorte que la version précédente reste chaude et que le retour en arrière soit presque instantané. Le coût est d'environ le double de la capacité pendant le déploiement, et chaque utilisateur se déplace au moment du basculement, de sorte qu'un problème qui n'apparaît que dans le cadre du trafic réel frappe tout le monde en même temps. Canari envoie d'abord une petite part du trafic réel vers la nouvelle version, ce qui fait apparaître des problèmes manqués par les vérifications synthétiques, mais il nécessite un routage du trafic et des métriques qui peuvent être découpées par version, cela prend plus de temps et expose sciemment certains utilisateurs à une version dans laquelle vous n'êtes pas encore sûr. Aucune des deux ne résout les modifications de la base de données : les deux supposent que la version précédente peut toujours s'exécuter sur le schéma actuel, c'est pourquoi les migrations sont généralement divisées en étapes d'extension et de contraction déployées séparément.
Quand un déploiement doit-il être automatiquement annulé ?
Lorsqu'un signal que le pipeline peut évaluer par lui-même dépasse un seuil convenu, pas lorsqu'une personne interprète un tableau de bord. En pratique, cela signifie un taux d'erreur, une latence ou une transaction commerciale nommée mesuré par rapport à l'objectif de niveau de service sur une fenêtre d'observation définie, le déploiement étant automatiquement interrompu ou inversé si la consommation du budget d'erreur est pire que la limite convenue. Deux choses font que cela fonctionne. Tout d’abord, répétez la restauration afin de connaître son fonctionnement et combien de temps cela prend. Deuxièmement, gardez le déploiement réversible en séparant les étapes irréversibles, principalement les migrations de schéma et les modifications unidirectionnelles des données, du déploiement du code, sinon l'automatisation tentera une restauration que les données ne peuvent pas prendre en charge.
Quelle est la place de l’approbation si nous déployons plusieurs fois par jour ?
L’approbation de chaque déploiement individuellement n’est pas évolutive et un processus que les gens ne peuvent pas suivre est contourné. La réponse habituelle est d'autoriser l'itinéraire plutôt que l'instance : définissez ce type de déploiement comme un changement standard pré-approuvé, avec les portes du pipeline, les tests et la restauration automatique comme contrôle, et réservez l'approbation individuelle pour les changements qui ne relèvent pas de ce modèle, comme les migrations de schéma ou tout ce qui touche un environnement restreint. C'est là que le message « Déploiement approuvé ? » La décision se trouve dans ce tableau, et c'est pourquoi la branche détenue est dessinée. Les cadres tels que SOC 2 (critère CC8.1) et le contrôle de gestion des modifications de la norme ISO/IEC 27001 exigent que les modifications apportées à la production soient autorisées, testées et documentées ; ils ne nécessitent pas de signature humaine à chaque déploiement. Un diagramme ne constitue pas une preuve en soi, mais les enregistrements de déploiement, les résultats des tests et les approbations qu'il produit sont ce qu'un évaluateur demande à voir.
Où ce processus s'inscrit
Dans la plupart des opérations, ce processus suit Diagramme du processus de gestion des changements (ITIL).
Précède
- Diagramme du processus de gestion des changements (ITIL) — Diagramme du processus de gestion des changements ITIL : accueil des RFC, tri standard, normal et urgence, approbation du CAB, planification, déploiement et retour arrière.