Organigramme du processus de publication du logiciel
Un organigramme du processus de publication de logiciels couvrant le gel de la portée, la porte de test automatisée, la préparation et l'UAT, l'approbation go/no-go, le déploiement, la restauration et les correctifs.
Qu'est-ce que le processus organigramme du processus de publication du logiciel ?
Un processus de publication de logiciel est l’ensemble des portes entre une construction complète du code et un système de production stable. Les étapes elles-mêmes sont familières (couper une branche, la construire, la tester, l'expédier), mais la valeur de l'écriture du processus réside dans les portes : le point où la portée cesse de changer, le point où une suite de tests défaillante renvoie le travail au développement plutôt qu'en avant, le point où quelqu'un avec l'autorité pour le faire dit d'y aller, et le point où une mauvaise version est annulée plutôt que débattue. Chaque porte laisse une trace de ce qu'il y avait dans la version, de ce qui a été testé, de qui l'a approuvé et de ce qui s'est passé après sa mise en ligne.
La plupart des problèmes de version sont des problèmes de transfert plutôt que des problèmes d'ingénierie. Une branche est coupée alors que trois autres fusions sont encore en cours, de sorte que personne ne peut dire ce qu'il y a réellement dans la construction. L'assurance qualité exécute un pack de régression sur un environnement de test qui s'est éloigné de la production il y a des mois. L'appel go/no-go se produit lors d'un appel vidéo sans critères écrits, donc l'opinion la plus forte l'emporte. Une version est publiée en fin d'après-midi sans période de surveillance convenue, et le premier signe de problème est un e-mail client le lendemain matin. Dessiner le flux sous forme de couloirs rend chaque transfert explicite et montre qui détient la version à un moment donné.
Ce modèle est un flux de version de travail réparti sur cinq voies : développement, assurance qualité, responsable des versions, opérations et propriétaire du produit, réparti en cinq phases, du gel de la portée à la fermeture. Il comprend les trois boucles que les équipes laissent généralement inutilisées, à savoir la porte de test automatisée qui renvoie les échecs à la branche de publication, la décision de non-participation qui renvoie une version pour retravailler plutôt que de la sortir, et le chemin de correctif qui permet à un défaut post-publication de réintégrer le déploiement et la vérification sans que personne n'invente un processus parallèle.
Ce que couvre cet organigramme
Dans ce modèle
- Portée et branchement sur les trois premières voies : code terminé en développement, assurance qualité confirmant la portée du test et les critères d'entrée, puis le gestionnaire de versions gele la portée et coupe la branche de version.
- La porte de test automatisée : le développement construit et exécute les tests automatisés, puis le contrôle qualité possède la « Réussite des tests automatisés ? » décision, qui renvoie les échecs à « Corriger les défauts sur la branche de publication » et les renvoie dans la construction plutôt que de les transmettre.
- Staging et UAT comme trois transferts distincts : les opérations déploient la version vers la pré-production, le contrôle qualité exécute des tests de régression sur celle-ci, et le propriétaire du produit exécute l'UAT et enregistre l'approbation.
- Approbation sous forme d'enregistrement plus décision : le responsable des versions rassemble un enregistrement de préparation à la publication, le propriétaire du produit approuve la version pour la production et la réponse "Feu vert pour la mise en production ?" la décision soit le libère, soit le renvoie à l’étape de correction du défaut.
- Le chemin de production dans le couloir Opérations : déployer dans la fenêtre de publication, exécuter des tests de fumée de production, puis un message « Release healthy ? » décision qui achemine une version défaillante vers « Revenir à la version précédente » et revenir à la correction des défauts.
- Surveillance et fermeture : une période de trempage définie, un « Défaut de production constaté ? » décision alimentant la boucle du correctif via le déploiement et les tests de fumée, et une étape finale en publiant les notes de version et en clôturant la version.
Quand utiliser ce modèle
- Écrire ou réécrire une procédure de publication pour une équipe qui a diffusé des discussions d'habitudes et de discussion et qui a besoin d'une image convenue avant qu'elle ne soit encodée dans un pipeline.
- Intégrer de nouveaux ingénieurs, analystes QA ou personnel de garde qui ont besoin de savoir quelle porte ils possèdent et ce qui se passe en aval s'ils la bloquent.
- Décider qui fait réellement l'appel de go/no-go, et selon quels critères, avant la prochaine version, force le débat.
- Répondre à un questionnaire de sécurité client ou à une demande d'audit interne sur la manière dont les modifications sont testées, approuvées et annulées.
- Révision du processus après une mauvaise version, la discussion porte donc sur quelle porte a été ignorée plutôt que sur une reconstruction de mémoire.
Comment cela fonctionne
Renommez les voies selon vos vrais rôles
Remplacez le développement, l'assurance qualité, le responsable des versions, les opérations et le propriétaire du produit par les rôles que vous avez réellement. De nombreuses équipes n'ont pas de gestionnaire de versions dédié, auquel cas fusionnez cette voie avec la direction de l'ingénierie plutôt que de laisser une bande vide. Si vous n'avez pas d'équipe opérationnelle distincte, intégrez le déploiement au développement et indiquez-le sur le graphique.
Définir ce que signifie le gel de la portée
Écrivez votre règle de gel à côté de l'étape de coupe de branche : ce qui peut encore atterrir sur la branche de publication après la coupe, qui autorise une exception et comment la branche est étiquetée. Enregistrez le commit d'où provient la branche, car c'est ce qui rend la construction reproductible et vous permet de générer des notes de version à partir du diff.
Définir ce que signifie « réussir » à chaque porte de test
Le message « Les tests automatisés réussissent ? » la décision est aussi bonne que sa définition. Indiquez quelles suites doivent être vertes, quel flocon ou seuil de couverture vous acceptez et qui peut remplacer une version rouge. Faites de même pour le pack de régression intermédiaire et pour l'UAT, afin que le propriétaire du produit sache ce qu'il signe.
Écrivez les critères go/no-go avant d’en avoir besoin
Remplacez la décision générique par votre propre liste de contrôle : aucun défaut critique ouvert, un retour en arrière répété, une couverture d'astreinte confirmée, des équipes dépendantes notifiées et une heure limite indiquée. Nommez qui préside l’appel et qui peut y opposer son veto. Accepter cela alors qu'une version est déjà en attente est la façon dont les mauvaises versions sont approuvées.
Définir le déclencheur de restauration, la période de trempage et l'itinéraire du correctif
Dites ce qui rend « Libération saine ? » réponse échouée : un taux d'erreur spécifique, un seuil de latence ou un test de fumée échoué, pas une décision de jugement. Définissez la durée de la période de trempage et ce qui est surveillé. Décidez ensuite de quelle approbation un correctif a besoin, qui peut en autoriser un en dehors des heures d'ouverture et comment il est fusionné avec la ligne principale, car un correctif qui ne réside que sur la branche de publication est une source commune de la prochaine régression.
Publiez-le et conservez une version actuelle
Partagez le diagramme où le travail se déroule, à côté de la liste de contrôle de publication ou dans le runbook, et obtenez l'approbation des personnes qui y sont nommées. Conservez les versions antérieures afin de pouvoir indiquer quand la procédure a changé et pourquoi, et examinez-la après toute version qui s'est mal déroulée.
Questions fréquentes
Quelles sont les étapes d’un processus de publication d’un logiciel ?
Cinq étapes couvrent la plupart des équipes. Tout d'abord, la portée et la branche : acceptez le contenu de la version, confirmez les critères d'entrée au test, gelez la portée et coupez la branche de la version. Deuxièmement, créez et testez : produisez une version candidate, exécutez la suite automatisée et renvoyez les échecs à la succursale au lieu de les transmettre. Troisièmement, la préparation et l'UAT : déployez dans un environnement de préparation, exécutez des tests de régression et obtenez l'approbation de l'UAT du propriétaire du produit. Quatrièmement, l’approbation : dressez un dossier de préparation et prenez une décision explicite d’aller ou non. Cinquièmement, publication et surveillance : déployez dans la fenêtre convenue, effectuez des tests de fumée, surveillez une période d'absorption définie, puis publiez les notes de version et fermez la version.
Quelle est la différence entre un processus de publication et un pipeline de déploiement ?
Un pipeline de déploiement est l'automatisation : il crée, teste et envoie du code sur un déclencheur. Le processus de publication correspond à la prise de décision, notamment qui a accepté la portée, qui a confirmé que les tests étaient significatifs, qui a approuvé la production, que se passe-t-il lorsque la version tourne mal et quand l'équipe peut se retirer. Un pipeline mature supprime les étapes manuelles mais ne supprime pas les décisions. Ce graphique montre délibérément les décisions en tant que décisions, afin que vous puissiez voir lesquelles d'entre elles votre pipeline applique déjà et lesquelles dépendent encore de la mémorisation de quelqu'un.
Qui doit prendre la décision de procéder ou non, et sur quoi doit-elle se baser ?
Une personne nommée doit le présider, généralement le responsable de la publication ou le propriétaire de la production, l'approbation du propriétaire du produit étant déjà enregistrée comme contribution plutôt que débattue lors de l'appel. Basez-le sur des critères écrits avant la sortie : aucun défaut critique ouvert, régression et UAT terminées, rollback répété, astreinte confirmée, équipes dépendantes notifiées. Enregistrez qui a participé et ce qui a été décidé, pas seulement le résultat. Si vous êtes audité selon SOC 2, le critère pertinent est CC8.1, qui attend que les modifications soient autorisées, testées, approuvées et documentées ; le dossier de préparation et la piste d'approbation en sont la preuve, et le diagramme montre où ils sont produits.
Comment gérer les correctifs sans contourner le processus de publication ?
Un correctif compresse le processus, il ne l'ignore pas. Dans ce modèle, un défaut détecté au cours de la période de surveillance est dirigé vers « Créer et tester un correctif » dans la voie de développement, puis réapparaît lors du déploiement et passe par les mêmes tests de fumée de production et le même « Version saine ? vérifier comme une version planifiée. Ce qui change, c'est la vitesse d'approbation, pas la vérification. Deux règles garantissent l'honnêteté : convenir à l'avance de qui peut autoriser un correctif en dehors des heures d'ouverture et fusionner le correctif avec la ligne principale le même jour, car un correctif qui n'existe que sur la branche de publication réapparaît sous forme de régression dans la version suivante.
Où ce processus s'inscrit
Dans la plupart des opérations, ce processus suit Diagramme du processus de gestion des changements (ITIL).
C'est une étape de Gestion des services informatiques.
Étape 2: 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.
Étape 3: Organigramme du processus de publication du logiciel Vous êtes ici
Un organigramme du processus de publication de logiciels couvrant le gel de la portée, la porte de test automatisée, la préparation et l'UAT, l'approbation go/no-go, le déploiement, la restauration et les correctifs.