Environnements basés sur Git : pourquoi traiter l'infrastructure comme du code permet d'obtenir des builds cohérents à chaque fois

À un moment donné dans leur parcours, tous les développeurs ont déjà été confrontés à un problème de type « mais ça fonctionne parfaitement en préproduction ». Puis, le code est fusionné en production, et quelque chose ne fonctionne plus. Il peut s'agir d'une variable d'environnement manquante, d'une incompatibilité entre les versions d'un service, d'une configuration qui a dérivé dans l'environnement sans que personne ne s'en aperçoive. Les raisons peuvent être nombreuses. 

C'est alors que commence la course effrénée post-déploiement. Vous fouillez dans les tableaux de bord, comparez les paramètres et essayez de reconstituer ce qui fonctionne réellement en production par rapport à ce que vous avez testé. Quelques heures plus tard, vous trouvez le coupable : quelqu'un a modifié un paramètre en phase de test il y a trois semaines, mais ne l'a jamais documenté.

C'est le prix à payer pour gérer l'infrastructure en dehors de votre base de code. Et cela s'aggrave avec chaque membre de l'équipe, chaque branche et chaque déploiement.

Les environnements basés sur Git résolvent ce problème en intégrant l'ensemble de la définition de votre infrastructure (applications, services, routes et logique de construction) dans un code contrôlé par version. Chaque branche devient un environnement déployable et aligné sur la production.

La véritable raison pour laquelle les builds sont incohérents

La dérive de l'environnement se produit lorsque le développement, la préproduction et la production ne sont plus synchronisés. Il s'agit rarement d'une seule erreur majeure, mais plutôt de dizaines de petites erreurs :

• Quelqu'un met à jour une version de la base de données en préproduction via un tableau de bord, mais oublie de faire de même en développement.
• Une commande de construction est modifiée en production. La modification n'atteint jamais le dépôt.
• Un nouveau membre de l'équipe lance un environnement local à l'aide de documents de configuration obsolètes.

Chaque modification est invisible. Il n'y a pas de commit, pas de pull request, pas de piste d'audit. Au fil du temps, vos environnements divergent silencieusement jusqu'à ce que quelque chose qui fonctionnait partout ailleurs tombe en panne en production.

Le coût n'est pas théorique. Pour de nombreuses organisations, demander un nouvel espace pour une application signifie soumettre plusieurs tickets à plusieurs équipes et attendre une à deux semaines. La mise à niveau d'un runtime ou d'une version de service peut prendre des mois. Avant même de commencer à travailler sur un produit, les équipes passent généralement un sprint entier, soit dix jours d'efforts de toute l'équipe, à mettre en place l'infrastructure et les pipelines CI. C'est du temps de développement de fonctionnalités perdu avant même qu'une seule ligne de code du produit ne soit livrée.

Comment le processus Git change tout

L'infrastructure basée sur Git traite votre référentiel comme la source faisant autorité pour le fonctionnement de votre application. Chaque configuration d'environnement est stockée dans le contrôle de version avec votre code. Lorsque vous poussez une branche, la plateforme lit votre fichier de configuration et fournit tout ce qui est nécessaire pour exécuter cette version précise de votre application.

Cette approche offre des avantages concrets. 

Tout d'abord, la parité des environnements devient automatique. Le même fichier de configuration est déployé pour le développement, la mise en scène et la production. Les différences spécifiques à chaque environnement sont gérées par des variables, et non par des configurations différentes. 

Deuxièmement, les modifications de l'infrastructure sont soumises à une révision du code. Modifier l'infrastructure signifie éditer des fichiers et créer des pull requests. Votre équipe examine les modifications de l'infrastructure avec la même rigueur que les modifications de l'application. 

Enfin, la restauration devient triviale. Les déploiements sont des processus déterministes basés sur les commits Git. La restauration des modifications de l'infrastructure est aussi simple que la restauration des commits.

Le fichier de configuration sert également de documentation qui reste à jour. Lorsque tout est dans le code, il n'y a pas de décalage entre ce que dit la documentation et ce qui s'exécute réellement.

Chaque branche Git devient un environnement en direct

Avec les processus basés sur Git, la création d'un environnement de test se résume à une seule action : pousser une branche. La plateforme provisionne automatiquement un environnement isolé qui hérite des données et des services de son parent. Les bases de données, le stockage réseau, les files d'attente et les configurations de routage sont tous répliqués automatiquement.

Cela change la façon dont les équipes travaillent. Les développeurs peuvent tester des migrations risquées sur des données de production clonées sans toucher à l'environnement réel. Les éditeurs de contenu peuvent vérifier les modifications dans les URL de prévisualisation pendant que les développeurs affinent la logique de l'API. L'équipe d'assurance qualité peut effectuer des tests de bout en bout dans des environnements qui reflètent exactement la production.

Une fois l'expérience terminée, la suppression de la branche détruit automatiquement l'environnement. Pas de tickets de nettoyage. Pas de ressources orphelines. Pas d'infrastructure oubliée qui accumule des coûts.

Les bogues obscurs, dépendants des données, se reproduisent instantanément lorsque votre environnement de test contient des données et des ressources réelles. La dérive de l'environnement disparaît de la conversation, car chaque branche est clonée à partir de sa branche parente par défaut. La parité n'est pas une réflexion après coup, c'est le point de départ.

Une évolutivité sans complexité

Les stacks Terraform et Kubernetes gérés manuellement introduisent un couplage caché et une fragilité que les équipes sous-estiment souvent. Les mises à niveau de version nécessitent l'apprentissage d'une nouvelle syntaxe. Les fichiers de configuration datant de plusieurs années peuvent ne plus fonctionner avec les outils actuels. La complexité s'accroît à mesure que la taille de l'équipe augmente et que davantage de personnes interviennent sur l'infrastructure.

Les plateformes basées sur Git réduisent le nombre de décisions que les développeurs doivent prendre. Les configurations d'infrastructure qui nécessiteraient autrement des fichiers Terraform, des manifestes Kubernetes et des définitions de pipeline CI/CD distincts sont regroupées dans un seul fichier déclaratif. La plateforme valide la syntaxe lors de la mise à jour et affiche les erreurs dans les journaux de compilation avant que la mauvaise configuration n'atteigne les réviseurs.

Lors de la gestion d'environnements à grande échelle, le fait de savoir que tous les environnements créés à partir de la même branche sont identiques élimine toute une série de sessions de débogage. Les divergences de configuration entre les environnements deviennent impossibles. Une fois qu'une fonctionnalité est vérifiée dans un environnement, elle fonctionne de manière identique dans tous les environnements exécutant cette configuration.

Comment Upsun met en œuvre des environnements basés sur Git

Upsun traite votre référentiel Git comme la seule source fiable pour le code de l'application et l'infrastructure. Un fichier d'.upsun/config.yamls unifié définit votre runtime, vos services, vos routes et vos variables d'environnement. Cette configuration accompagne votre code, ce qui élimine le décalage entre ce qui fonctionne localement et ce qui s'exécute en production.

Chaque push lance un stack de conteneurs isolé. Vous pouvez créer une branche de ce stack, données incluses, dans un nouvel environnement de test en moins d'une minute. La CLI et l'API permettent aux équipes d'automatiser l'intégration avec les processus CI/CD existants sans tout réorganiser.

Les intégrations de sources avec GitHub, GitLab et Bitbucket permettent de créer automatiquement des environnements pour les pull requests et les branches. Lorsqu'une demande de fusion s'ouvre, un environnement est lancé avec la branche cible comme parent et une copie des données de son parent. Fusionnez la demande et l'environnement de test est automatiquement supprimé.

L'infrastructure en lecture seule garantit la reproductibilité. Les fichiers ne peuvent pas être modifiés lors de l'exécution. Ainsi, lorsque vous fusionnez le code de la préproduction à la production, vous déployez une image du système de fichiers identique. Il n'y a pas de dérive de configuration, pas de modifications manuelles et pas de divergences entre ce qui a passé les tests et ce qui est exécuté en direct.

Aller de l'avant

L'infrastructure doit être une dépendance de votre application, comme n'importe quelle autre dépendance. Au-delà du contrat entre le code de l'application et un service, les développeurs ne devraient pas avoir à se soucier de la manière dont ce service est fourni ou configuré.

Les environnements basés sur Git rendent cela possible. Chaque branche devient un environnement déployable. Chaque modification de configuration est soumise à un examen. Chaque déploiement est reproductible à partir du système de contrôle de version.

Il en résulte des boucles de rétroaction plus rapides, moins de surprises après le déploiement et plus de temps consacré à la création de fonctionnalités plutôt qu'au débogage des incohérences de l'environnement.

Prêt à éliminer les dérives de configuration ? Commencez un essai gratuit d'Upsun et découvrez le déploiement basé sur Git.