Les changements d'infrastructure nécessitent une revue de code, tout comme le code applicatif
Vous avez un serveur en production. Un membre de votre équipe doit ouvrir un nouveau port pour un outil de monitoring. Il se connecte à la console cloud, trouve le groupe de sécurité, ajoute la règle et enregistre. Personne d'autre n'est au courant. Trois jours plus tard, l'équipe sécurité réalise un audit et découvre un port ouvert qui ne devrait pas l'être. Personne ne se souvient qui l'a ouvert ni pourquoi.
Ce scénario se produit dans les équipes qui traitent les changements d'infrastructure différemment des changements de code applicatif. La même équipe qui exige des pull requests, des revues par les pairs et des approbations pour un correctif d'une ligne dans son application laisse quelqu'un se connecter en SSH à un serveur et modifier directement les fichiers de configuration. Cette incohérence crée des risques, de la confusion et des interventions d'urgence inutiles.
Pourquoi les changements d'infrastructure méritent la même rigueur
Lorsque vous écrivez l'infrastructure en tant que code, vous stockez vos configurations de serveur, règles réseau, paramètres de base de données et définitions de déploiement dans Git. Ces fichiers décrivent exactement à quoi votre infrastructure doit ressembler. Une modification de ces fichiers peut avoir des conséquences aussi graves qu'une modification de votre code applicatif.
Considérez ce qui se passe lorsque quelqu'un modifie une règle de pare-feu. Un seul port mal configuré peut exposer les données clients sur Internet. Une taille d'instance de base de données incorrecte peut entraîner une dégradation des performances ou des pics de coûts inattendus. Un paramètre de répartiteur de charge erroné peut mettre hors ligne l'ensemble de votre application. Ces risques ne sont pas hypothétiques. Ils se produisent régulièrement dans les équipes qui négligent les processus de revue pour les changements d'infrastructure.
Le problème n'est pas que les gens commettent des erreurs. Tout le monde en commet. Le problème est que lorsque les changements d'infrastructure se produisent sans revue, les erreurs passent inaperçues jusqu'à ce que quelque chose se casse. Et quand quelque chose se casse, il n'y a aucune trace de ce qui a changé, qui l'a changé, ni pourquoi.
Comment fonctionnent les pull requests pour l'infrastructure
Si votre infrastructure est définie comme du code dans Git, le processus de revue fonctionne exactement comme pour le code applicatif. Quelqu'un crée une branche, apporte ses modifications aux fichiers d'infrastructure et ouvre une pull request. Les autres membres de l'équipe examinent les changements, laissent des commentaires, demandent des améliorations ou approuvent la modification. Une fois approuvée, la modification est fusionnée dans la branche principale, et le pipeline l'applique.
Ce processus n'est ni nouveau ni compliqué. C'est le même workflow que les équipes de développement utilisent depuis des années. La seule différence réside dans ce qui est examiné. Au lieu de passer en revue la logique applicative, vous examinez des définitions de configuration.
Que vérifier lors de la revue d'infrastructure
Lorsque vous examinez une pull request d'infrastructure, vous recherchez plusieurs éléments.
Premièrement, la modification a-t-elle un sens par rapport au besoin ? Si quelqu'un ouvre un port, a-t-il réellement besoin de ce port ? Existe-t-il une alternative plus sécurisée ? La modification est-elle conforme à ce que l'équipe a convenu ?
Deuxièmement, la configuration est-elle correcte ? Vérifiez la syntaxe. Assurez-vous que les numéros de port, les tailles d'instance et les blocs CIDR réseau sont exacts. Recherchez les règles de sécurité trop permissives. Une règle qui autorise le trafic depuis 0.0.0.0/0 vers le port 22 est presque toujours un signal d'alarme.
Troisièmement, la modification est-elle cohérente avec les autres environnements ? Si votre environnement de staging utilise un type d'instance spécifique ou une taille de base de données particulière, l'environnement de production ne devrait pas soudainement utiliser quelque chose de complètement différent sans raison documentée. Les incohérences entre environnements sont une source courante de problèmes de déploiement.
Quatrièmement, la modification respecte-t-elle les conventions de nommage et les normes d'étiquetage de votre équipe ? Un nommage cohérent facilite la compréhension des ressources et de leurs propriétaires. Les étiquettes aident à la répartition des coûts et à la gestion des ressources.
L'historique
Chaque pull request approuvée et fusionnée devient un enregistrement permanent de ce qui a changé, qui l'a changé et quand. Cette trace historique est inestimable quand les choses tournent mal.
Imaginez vous réveiller et constater que votre application de production est inaccessible. Vous vérifiez les modifications récentes de votre dépôt d'infrastructure et voyez une pull request qui a modifié la configuration du répartiteur de charge il y a deux heures. Vous pouvez immédiatement voir ce qui a changé, en discuter avec la personne à l'origine de la modification et décider de revenir en arrière ou de corriger.
Sans cet historique, vous seriez réduit à des suppositions. Vous demanderiez autour de vous, consulteriez les journaux de chat et examineriez les journaux d'activité de la console cloud. Le processus prend plus de temps et est moins fiable. L'historique des pull requests vous donne une réponse directe.
Répondre à la préoccupation de rapidité
Certaines équipes résistent aux revues d'infrastructure parce qu'elles pensent que cela ralentit les choses. Elles soutiennent que les changements d'infrastructure doivent se produire rapidement, surtout lors d'incidents ou de mises à jour urgentes.
La réalité est que le temps passé en revue est presque toujours inférieur au temps passé à récupérer d'un changement non revu qui a cassé la production. Une revue de cinq minutes peut éviter une panne de deux heures. Le calcul est simple.
Pour les changements urgents lors d'incidents, vous pouvez adapter le processus. Certaines équipes utilisent un modèle de revue post-incident où le changement est appliqué d'abord pour restaurer le service, et la pull request est créée et examinée ensuite. L'essentiel est que la revue a toujours lieu et que le changement est toujours documenté. Le processus s'adapte aux urgences mais ne disparaît pas.
Ce qui vient après la revue
Une fois que le changement d'infrastructure a passé la revue et a été fusionné, le travail n'est pas terminé. Le pipeline doit montrer ce qui va réellement changer avant d'appliquer. C'est l'étape de planification. Le pipeline compare l'état souhaité défini dans votre code avec l'état actuel de votre infrastructure et affiche les différences. Ce n'est qu'après avoir examiné le plan et confirmé qu'il semble correct que le pipeline procède à l'application des modifications.
Cette étape de planification est cruciale. Même avec une revue de code approfondie, le plan peut révéler des effets inattendus. Un changement qui semble correct dans le code pourrait produire un plan qui supprime et recrée des ressources, ce qui pourrait entraîner des temps d'arrêt. Le plan vous donne une dernière chance de détecter les problèmes avant qu'ils n'atteignent la production.
Liste de contrôle pratique pour les pull requests d'infrastructure
- La modification correspond-elle au besoin ou à la demande réelle ?
- Toutes les valeurs sont-elles correctes (ports, tailles d'instance, plages CIDR) ?
- Les règles de sécurité sont-elles aussi restrictives que possible tout en autorisant le trafic nécessaire ?
- La modification est-elle cohérente avec les autres environnements ?
- Respecte-t-elle les conventions de nommage et d'étiquetage ?
- Existe-t-il un résultat de plan montrant ce qui changera avant l'application ?
À retenir
Les changements d'infrastructure méritent le même processus de revue que les changements de code applicatif. Les conséquences d'un mauvais changement d'infrastructure sont souvent plus graves et plus difficiles à diagnostiquer qu'un mauvais changement de code. Les pull requests offrent un moyen structuré de détecter les erreurs, d'appliquer les normes et de maintenir un historique. Le temps que vous investissez dans la revue des changements d'infrastructure est du temps que vous ne passerez pas à déboguer des pannes de production causées par des modifications de configuration non revues. Traitez votre code d'infrastructure avec le même soin que votre code applicatif, et votre environnement de production vous en remerciera.