Modèle de logigramme de pipeline CI/CD

Un pipeline fonctionne mieux sous forme de flux de décision, car l'intérêt réside dans ce qui arrête un commit plutôt que dans la suite de jobs qui l'exécute. Nous vous recommandons la démarche suivante :

1. Listez toutes les issues possibles d'un commit : production, merge bloqué, rollback.
2. Notez les filtres qui les séparent, et indiquez lesquels sont automatisés et lesquels nécessitent une personne.
3. Transformez chaque filtre en nœud de décision en dessinant ses deux sorties, y compris les chemins d'échec.
4. Vérifiez que chaque chemin aboutit. Un diagramme de pipeline avec une branche en suspens, c'est là qu'un déploiement échoué passe inaperçu.
5. Dessinez-le dans l'outil que votre public utilise déjà. Un modèle gratuit vous épargne l'essentiel de la mise en page.

La livraison continue signifie que chaque build qui réussit est prêt à être mis en production, mais qu'une personne décide du moment. Le déploiement continu signifie que chaque build qui réussit part automatiquement en production, sans intervention humaine.

Le filtre d'approbation de ce diagramme fait toute la différence. Supprimez-le, et le même pipeline devient du déploiement continu. Ce choix mérite d'être fait en connaissance de cause : les équipes parlent souvent de déploiement alors qu'elles pratiquent la livraison, et découvrent l'écart lors d'un audit.

L'intégration continue couvre tout ce qui précède le filtre des tests : fusionner le code fréquemment et prouver automatiquement qu'il compile et passe les tests. La livraison ou le déploiement continu couvre tout ce qui suit : amener ce build vérifié en staging, puis en production.

Sur ce diagramme, la CI se termine à la décision « tests réussis » et la CD commence au déploiement en staging. Cette séparation n'est pas théorique : les deux échouent généralement pour des raisons différentes et relèvent souvent de personnes différentes.

Chacun arrête un commit pour une raison différente :

• Tests réussis : automatisé, objectif et rapide. Un « non » notifie l'auteur et bloque le merge.
• Filtre d'approbation : humain, fondé sur le jugement et plus lent. Un « non » déclenche un rollback et arrête le pipeline au lieu de réessayer.

Ajoutez un filtre supplémentaire pour l'analyse de sécurité, les budgets de performance ou une revue du comité consultatif des changements : les branches restent attachées pendant que le diagramme se réorganise.

L'étape « build et exécution des tests » utilise la forme de processus prédéfini plutôt qu'un simple rectangle. Dans la notation des logigrammes, elle désigne une étape décrite en détail ailleurs, en l'occurrence dans la configuration des jobs de votre système de CI.

C'est un signal utile sur une diapositive. Il indique au lecteur que la forme résume un pipeline qu'il peut aller consulter, plutôt qu'une action unique, sans encombrer le diagramme avec chaque étape de test.

Le commit sort vers « notifier et bloquer le merge ». Les deux moitiés comptent : notifier sans bloquer, c'est laisser l'échec être ignoré ; bloquer sans notifier, c'est laisser l'auteur l'apprendre par quelqu'un d'autre.

Le représenter comme une issue finale plutôt que comme une boucle de retour est délibéré. Un build en échec n'est pas relancé par le pipeline : il est renvoyé à la personne qui a écrit le code, ce qui confie la correction à celle qui a le contexte.

Tout dépend de ce contre quoi vous vous protégez. Un filtre manuel repère ce que l'automatisation ne peut pas juger : une mise en production risquée avant un week-end férié, un changement qui nécessite de prévenir d'abord un client, une exigence de conformité imposant la séparation des tâches. Il vous coûte aussi en vitesse et devient une simple formalité si personne ne dit jamais non.

Un test raisonnable : si votre approbateur n'a rien refusé en six mois, le filtre est de la pure forme, et vous devriez soit l'automatiser, soit ajouter les critères qui rendraient un refus possible.

Chaque filtre doit avoir un responsable nommé, et il s'agit rarement de la même équipe :

• Développeurs : le commit et la correction de tout ce que bloque le filtre des tests.
• Plateforme ou DevOps : la configuration du build, l'environnement de staging et le mécanisme de rollback.
• Release manager ou tech lead : la décision d'approbation elle-même.
• Sécurité ou conformité : les critères que vérifie le filtre, le cas échéant.

Si la même personne écrit le code et approuve la mise en production, le filtre n'assure pas la séparation qu'il semble garantir.

PowerPoint le permet avec SmartArt et la Shapes gallery, mais le travail est manuel : vous placez vous-même chaque losange, étiquetez les deux sorties et rattachez les connecteurs à chaque déplacement. Pour un pipeline comportant deux filtres et trois issues finales, c'est précisément ce qui fait que le diagramme cesse d'être mis à jour.

Il est plus rapide de passer par l'onglet Lucen Flowchart, qui aimante les connecteurs aux points d'ancrage des formes et réorganise le diagramme avec Auto Layout lorsque vous ajoutez un filtre. Dans les deux cas, le résultat reste un ensemble d'objets PowerPoint natifs sur votre diapositive.

Le fichier téléchargé est un .pptx gratuit composé de formes PowerPoint natives : tout le monde peut l'ouvrir, le lire et le modifier, et vous pouvez le partager comme n'importe quelle présentation. Les destinataires n'ont rien à installer.

Les connecteurs intelligents, Auto Layout et Lucen AI sont fournis par le complément Lucen Flowchart, qui ajoute un onglet Lucen Flowchart au ruban et fonctionne sous Windows avec PowerPoint 2016 ou version ultérieure, ainsi qu'avec PowerPoint pour Microsoft 365. PowerPoint pour le web, Mac et mobile ne sont pas pris en charge. Les étapes d'installation et de dépannage sont disponibles sur Lucen Support.