Finis les conflits d'environnement : comment E-Pods permet à chaque développeur de SnapLogic de disposer de son propre clone de production

Les équipes d'ingénieurs sont confrontées à un défi majeur : comment tester des fonctionnalités dans des environnements proches de la production sans compromettre la stabilité, faire grimper les coûts ou entraver le travail des autres développeurs ? Le modèle traditionnel d'environnement de préproduction partagé crée des goulots d'étranglement, génère de l'instabilité et ralentit la vitesse de déploiement. Parallèlement, la mise en place de clones complets de l'infrastructure pour chaque développeur est d'un coût prohibitif et d'une complexité opérationnelle trop élevée.

Nous avons développé E-Pods (Ephemeral Pods) pour répondre à ce problème : il s'agit d'un cadre basé sur le GitOps qui fournit aux développeurs des environnements à la demande, isolés et similaires à ceux de production, grâce à un simple workflow de pull request. Cet article explique comment E-Pods permet de mettre en place des pratiques de développement soucieuses des coûts et des risques, tout en accélérant l'innovation.

Le problème de l'environnement partagé

Toute entreprise d'ingénierie ayant dépassé le stade d'une poignée de développeurs connaît les difficultés liées aux environnements de préproduction partagés. Le conflit est fondamental : les développeurs ont besoin de stabilité pour tester leurs modifications, mais ils doivent également déployer du code potentiellement instable pour valider ces modifications. Lorsque plusieurs équipes partagent le même environnement, c'est le chaos.

Imaginez le scénario suivant : l'équipe A déploie une modification compatible en arrière-plan pour tester une nouvelle fonctionnalité. Pendant ce temps, l'équipe B tente de présenter son travail aux parties prenantes. La vérification d'un correctif de bogue critique par l'équipe C est désormais bloquée car l'environnement est instable. Cela vous dit quelque chose ?

Les solutions traditionnelles présentent toutes des inconvénients :

• Les environnements de préproduction partagés: source de goulots d'étranglement, d'instabilité et de reproches mutuels en cas de panne
• Les environnements de développement à longue durée de vie: ils accumulent les dérives, deviennent coûteux et continuent de générer des conflits de planification
• Clonage complet de l'infrastructure: coût prohibitif et complexité opérationnelle à grande échelle
• Développement local uniquement: insuffisant pour tester les intégrations, les interactions entre microservices et les fonctionnalités dépendantes de l'infrastructure

Présentation des E-Pods : des environnements éphémères basés sur le GitOps

Les E-Pods adoptent une approche différente. Au lieu de gérer les workflows complexes de provisionnement d'environnements les workflows de procéder à des déploiements via plusieurs outils, les développeurs n'ont qu'à ouvrir une pull request sur GitHub. C'est tout. Le framework se charge du reste : provisionnement de l'infrastructure, déploiement des services, configuration du réseau et fourniture des identifiants d'accès.

Comment fonctionnent les E-Pods

Le fonctionnement des E-Pods est d'une simplicité élégante :

1. Ouvrez une demande de modification. Les développeurs créent une demande de modification dans notre dépôt E-Pods dédié, en précisant les services dont ils ont besoin ainsi que les versions souhaitées. Cette demande de modification devient alors la référence unique pour la configuration de l'environnement.

2. Fusionner et déployer. Une fois la pull request fusionnée, notre contrôleur GitOps (basé sur ArgoCD) détecte la modification et lance le provisionnement. Les étapes sont les suivantes :

• Crée des espaces de noms Kubernetes isolés
• Déploie les versions de service spécifiées
• Configure les règles de mise en réseau et de maillage de services
• Met en place la surveillance et l'observabilité
• Mise en place de bases de données temporaires

3. Recevoir les identifiants d'accès à l'environnement En quelques minutes, les développeurs reçoivent un e-mail contenant :

• URL d'accès à l'environnement
• Identifiants de connexion à l'interface utilisateur

4. Suivi via Slack : des mises à jour en temps réel sont envoyées sur Slack, permettant ainsi aux développeurs de rester informés sur :

• État d'avancement du déploiement
• Contrôles de l'état des services
• Adaptabilité à l'environnement

5. Gestion des versions via Kargo C'est là que les E-Pods se distinguent vraiment. Nous avons intégré Kargo, un outil de livraison continue qui offre une interface visuelle pour la gestion des versions. Les développeurs accèdent à une URL Kargo dédiée où ils peuvent :

• Consultez toutes les versions de service disponibles dans la « boutique »
• Passez à une version supérieure ou inférieure en un seul clic
• Suivre les étapes de promotion sur l'ensemble des services
• Consulter l'historique des déploiements et revenir à une version précédente si nécessaire

Kargo se synchronise avec notre système de CI (Travis CI dans notre cas) et récupère automatiquement les nouvelles images de conteneurs. Dès qu’une nouvelle version d’une branche de fonctionnalités est prête, les développeurs la voient immédiatement apparaître dans leur interface E-Pods Kargo.

6. Nettoyage automatique: les E-Pods sont conçus pour optimiser les coûts. Chaque environnement dispose d'une durée de vie prédéfinie. Avant l'arrêt :

• Les développeurs reçoivent une notification par e-mail les avertissant de la suppression imminente
• Ils peuvent prolonger la durée de vie de l'environnement
• Ou le supprimer manuellement via une pull request GitHub une fois les tests terminés

L'avantage du GitOps

Notre choix de mise en œuvre, GitOps, offre plusieurs avantages cumulés.

Configuration déclarative. Les définitions d'environnement sont stockées dans Git et fournissent :

• Historique des versions et pistes d'audit
• Restauration facile des configurations précédentes
• Révision par les pairs via les workflows PR
• Une documentation qui ne doit pas s'éloigner de la réalité

Le libre-service sans complexité. Les développeurs n'ont pas besoin de maîtriser Kubernetes, les Helm Charts ou l'infrastructure en tant que code. Ils travaillent avec les workflows Git familiers les workflows des fichiers de configuration YAML.

Réconciliation et détection des écarts. Le contrôleur GitOps réconcilie en permanence l'état souhaité (dans Git) avec l'état réel (dans le cluster). Si quelqu'un modifie manuellement un E-Pod, le contrôleur le corrige automatiquement.

Intégration aux les workflows existants. Étant donné que les équipes de développement utilisent déjà GitHub pour la révision du code, l'ajout de la mise en place d'environnements au même workflow n'entraîne aucune charge cognitive supplémentaire.

Impact concret : la transformation de l'expérience des développeurs

Depuis la mise en place des E-Pods, nous avons constaté des améliorations notables à plusieurs niveaux :

Améliorations en termes de vitesse

Avant les E-Pods :

• Délai moyen pour obtenir un environnement de test : 2 à 3 jours (y compris la demande, la mise en place et l'attente de la disponibilité de l'environnement partagé)
• Conflits d'environnement : 3 à 5 par semaine nécessitant une résolution manuelle
• Échecs de déploiement dus à l'instabilité de l'environnement : environ 30 % des premières tentatives

Après les E-Pods :

• Durée moyenne nécessaire pour obtenir un environnement de test : 3 à 5 minutes (de la fusion de la pull request à la mise en service)
• Conflits d'environnement : zéro (isolation totale)
• Failed deployments due to environment issues: <5%

Rentabilité

Grâce à la mise en place d'un nettoyage automatique et d'une allocation des ressources adaptée aux besoins, nous avons obtenu :

• Réduction des coûts liés aux infrastructures de développement
• Réduction de la consommation des ressources inutilisées
• Suppression des environnements de développement obsolètes et tombés dans l'oubli

Satisfaction des développeurs

Les retours qualitatifs ont été extrêmement positifs :

• Les développeurs indiquent consacrer moins de temps à la gestion de l'environnement et davantage au codage
• Moins de frictions dans la collaboration entre équipes (fini les conflits d'horaires)
• Validation plus rapide des fonctionnalités et démonstrations destinées aux parties prenantes
• Moins de craintes quant à la rupture des environnements partagés

Les environnements éphémères comme avantage concurrentiel

Dans la course à l'accélération des cycles d'innovation et à une livraison de logiciels plus fiable, les environnements éphémères sont devenus un impératif concurrentiel. E-Pods démontre qu'en optant pour une architecture adaptée, en mettant en œuvre le GitOps, en maîtrisant les coûts, en isolant les risques et en adoptant les workflows centrés sur les développeurs, les entreprises peuvent offrir à ces derniers de puissantes capacités de test sans engager de coûts élevés ni alourdir la complexité opérationnelle.

L'avenir des environnements de développement est éphémère, isolé et à la demande. En considérant la mise à disposition des environnements comme du code, en s'intégrant aux les workflows existants les workflows développeurs et en intégrant la maîtrise des coûts dès la conception, E-Pods permet à nos équipes d'avancer plus vite tout en garantissant la stabilité et la fiabilité exigées par notre entreprise.