Stratégies de branchement pour IaC

La méthodologie Git typique utilise une branche de base principale (telle quemain) pour la production, une branche de développement et des branches de fonctionnalités. De nombreuses organisations adoptent instantanément cette même conception d'infrastructure sous forme de code (IaC). Cependant, la méthodologie Git n'est pas directement compatible avec les modèles de conception d'infrastructure courants. Tenez compte des points suivants :

• Les applications ont plusieurs environnements.

  • Les exemples d'environnement incluent le bac à sable, le développement, la mise en scène et la production.

• Les environnements ne sont pas étroitement liés.

  • La production est souvent étroitement liée à la réussite des déploiements intermédiaires.

  • La production et la mise en scène sont généralement totalement dissociées de l'environnement de développement.

  • Le développement est généralement entièrement découplé de l'environnement sandbox.

• Chaque application possède son propre ensemble de normes d'environnement.

  • De nombreuses applications n'utilisent pas d'environnement sandbox.

  • Certaines applications ne nécessitent pas d'environnement intermédiaire, mais utilisent plutôt une stratégie de déploiement bleu/vert.

Imaginez un scénario dans lequel un référentiel d'applications fournit trois environnements utilisant une méthodologie basée sur les troncs. L'environnement de développement est lié à la develop branche, le développement à la staging branche et la production à la main branche. Pour cette application, une nouvelle fonctionnalité est requise pour connecter une passerelle de transit dans la solution, qui est gérée par une autre équipe et un autre référentiel. Un développeur écrit le code d'infrastructure dans une branche de fonctionnalités et le fusionne avec la develop branche lorsqu'il est prêt. Tout semble aller pour le mieux.

Cependant, un défi se pose. Un autre développeur possède un récit utilisateur distinct pour une fonctionnalité distincte, l'écrit dans une branche de fonctionnalités et le fusionne avec la develop branche. La deuxième fonctionnalité est maintenant prête à être intégrée à la mise en scène et à la production. Cependant, la fonctionnalité de passerelle de transit d'origine n'est pas prête en raison d'un critère de risque dans l'organisation. Désormais, toutes les fonctionnalités sont bloquées, de la promotion à la production, et le code de l'application est effectivement gelé ou cassé.

Dans ce scénario, considérez les solutions potentielles suivantes :

• Solution la plus courante : augmentez la répétition du code (réduisez DRY) aux emplacements de structure de code ciblés en définissant ./environments des dossiers distincts dans le référentiel. Cela permet au code des environnements de se trouver dans le même référentiel, mais découplé.

• Configurez un processus CI/CD avec une gestion complexe des variables.

• Séparez les environnements dans des référentiels distincts.

• Solution la moins courante : utilisez plusieurs branches du tronc.