Ce que six organisations différentes m'ont appris sur le CI/CD
Chaque équipe d'ingénierie avec laquelle j'ai travaillé partait du même point : elles devaient livrer des changements là où les utilisateurs pouvaient les utiliser. Mais la façon dont elles construisaient leur processus de livraison était complètement différente selon leur profil.
Une startup de trois personnes n'a pas besoin du même pipeline qu'une entreprise fintech sous contrôle réglementaire. Une équipe mobile qui livre sur les stores d'applications fait face à des contraintes qu'une équipe de bases de données gérant des systèmes legacy n'a jamais envisagées. Pourtant, quand on regarde de près tous ces cas, les trois mêmes schémas émergent.
Le premier schéma : tout le monde part des mêmes besoins
Quelle que soit l'organisation, chaque équipe a besoin de trois choses :
- Un moyen d'envoyer des changements là où les utilisateurs peuvent y accéder
- La confiance que ces changements ne casseront rien
- Un moyen de corriger les problèmes quand ils apparaissent inévitablement
Une petite startup répond à ces besoins avec un pipeline simple et une surveillance basique. Une entreprise régulée ajoute des étapes d'approbation et des pistes d'audit. Une entreprise SaaS avec plusieurs équipes construit un catalogue de services et des golden paths. Une équipe mobile-first met en œuvre des déploiements progressifs et de la configuration à distance. Une équipe qui gère des bases de données legacy crée des stratégies de migration sécurisées. Une équipe centrée sur l'infrastructure ajoute de la gouvernance pour l'infrastructure-as-code et la détection de dérive.
Ce ne sont pas des approches différentes. Ce sont les mêmes réponses aux mêmes questions, juste avec des niveaux de complexité différents.
Le deuxième schéma : le risque détermine le niveau de sécurité nécessaire
Plus l'impact d'une erreur est grand, plus vous ajoutez de garde-fous.
Une petite startup peut tolérer quelques minutes d'indisponibilité car elle a peu d'utilisateurs. Une entreprise fintech ne peut tolérer une seule erreur de transaction car le risque touche directement les clients et les régulateurs. Une entreprise SaaS avec plusieurs équipes ne peut pas laisser une équipe casser le service d'une autre. Une équipe mobile-first ne peut pas pousser une mise à jour qui plante sur des milliers d'appareils. Une équipe gérant des bases de données legacy ne peut pas perdre de données car la récupération prend des jours. Une équipe centrée sur l'infrastructure ne peut pas laisser la configuration dériver car l'impact se propage sur tout le système.
Votre profil de risque détermine le niveau de rigueur de votre processus. Ne construisez pas plus de sécurité que votre risque réel ne l'exige. Ne construisez pas moins que ce que votre risque demande.
Le troisième schéma : l'automatisation n'est pas l'objectif
L'automatisation est un outil pour réduire le travail manuel répétitif. Personne n'automatise pour le plaisir d'automatiser.
Une startup automatise le déploiement parce qu'elle en a assez de se connecter aux serveurs à chaque fois. Une entreprise régulée automatise les pistes d'audit car enregistrer manuellement chaque décision est impossible. Une entreprise SaaS automatise les golden paths car elle ne peut pas former chaque nouvelle équipe de zéro. Une équipe mobile-first automatise les déploiements progressifs car contrôler des milliers d'appareils un par un n'est pas réalisable. Une équipe de bases de données legacy automatise les migrations car les changements manuels sont trop risqués. Une équipe d'infrastructure automatise la détection de dérive car vérifier l'infrastructure manuellement à grande échelle est impraticable.
L'automatisation résout une douleur spécifique. Si vous n'avez pas encore cette douleur, n'automatisez pas encore.
Où chaque organisation commence
La différence ne réside pas dans ce qu'elles construisent finalement. La différence est dans leur point de départ et ce qu'elles priorisent en premier.
Une startup commence par le pipeline le plus simple possible. Elle ajoute des garde-fous seulement quand quelque chose commence à faire mal.
Une entreprise régulée commence par la conformité. Ensuite, elle cherche à accélérer le processus sans perdre la conformité.
Une entreprise SaaS avec plusieurs équipes commence par la cohérence entre les équipes. Ensuite, elle ajoute de la flexibilité dans des limites convenues.
Une équipe mobile-first commence par le contrôle de la distribution. Ensuite, elle construit l'observabilité pour surveiller les effets de ses versions.
Une équipe de bases de données legacy commence par des schémas de migration sécurisés. Ensuite, elle corrige le processus de déploiement d'application autour.
Une équipe centrée sur l'infrastructure commence par la gouvernance. Ensuite, elle s'assure que les changements d'infrastructure ne perturbent pas les applications qui tournent dessus.
Comment appliquer cela à votre équipe
Il n'existe pas de schéma unique qui convienne à toutes les organisations. Mais il existe un cadre que vous pouvez utiliser pour déterminer votre propre point de départ.
D'abord, identifiez ce qui fait le plus mal en ce moment. Le déploiement est-il encore manuel ? Les erreurs ne sont-elles découvertes qu'après la mise en production ? Les changements de base de données vous rendent-ils nerveux ? L'infrastructure continue-t-elle de dériver par rapport à la configuration souhaitée ?
Ensuite, trouvez l'étude de cas qui correspond le mieux à votre situation. Si votre équipe est petite, commencez par le schéma startup. Si vous êtes sous contrôle réglementaire, commencez par le schéma entreprise régulée. Si vous avez plusieurs équipes, commencez par le schéma SaaS multi-équipes.
Troisièmement, construisez une couche de sécurité à la fois. Commencez par un pipeline simple. Ajoutez une surveillance basique. Ajoutez des étapes d'approbation uniquement pour les changements à haut risque. Ajoutez la couche suivante seulement quand le besoin se présente réellement.
Une checklist pratique rapide
Avant de concevoir votre prochain pipeline ou d'ajouter un autre outil, posez-vous ces questions :
- Quel est le risque réel si ce changement échoue ?
- Quelle étape manuelle cause le plus de friction en ce moment ?
- Puis-je résoudre cela avec une approche plus simple avant d'ajouter de l'automatisation ?
- Ce garde-fou correspond-il au niveau de risque réel, ou suis-je en train de sur-ingénierie ?
L'essentiel à retenir
Votre processus de livraison évoluera à mesure que votre équipe, votre produit et vos risques grandissent. Ne copiez pas le pipeline de quelqu'un d'autre. Comprenez ce dont vous avez réellement besoin maintenant, construisez la chose la plus simple qui réponde à ce besoin, et n'ajoutez de la complexité que lorsque la douleur le justifie. Le schéma qui fonctionne pour vous aujourd'hui ne sera pas celui dont vous aurez besoin l'année prochaine. C'est normal. C'est ainsi que les bonnes organisations d'ingénierie évoluent.