Quel est le quotidien de nos consultants en mission ? Quels sont les challenges techniques qu’ils doivent relever et quelles solutions sont apportées ? Derrière une mise en production réussie, un déploiement ou un Proof of Concept, il y a des consultants, une équipe, des technologies et beaucoup d’expertise et d’intelligence collective ! Cette série d’articles vise à vous dévoiler l’envers du décor, à travers le témoignage de nos consultants.

Comment développer des compétences DevOps quand on a essentiellement un background en environnement de production Windows ? Armé d’un poste Linux et de bonne volonté, Prajeeth s’est plongé dans Git, Docker et AWS pour les besoins du projet Renault Digital, et il partage ici avec nous son retour d’expérience sur ce projet d’intégration continue et d’automatisation du déploiement des applications.

Sur quel projet de Continuous Deployment travailles-tu ?

Il s’agit de mettre en place une chaîne CI/CD afin d’assurer l’intégration continue et l’automatisation du déploiement des applications. Cette chaîne CI/CD s’appuie notamment sur Gitlab et Gitlab-ci pour l’intégration continue, Docker et divers services AWS comme l’orchestrateur de conteneurs ECS, les bases de données RDS, le stockage S3 pour le déploiement continu. Les environnements applicatifs sont construits au préalable via Terraform.

Comment ça fonctionne ?

Les modèles de déploiement sont essentiellement basés sur des applications en Java et Node.js et ont été mis en place par Rodrigue et Clément de la cellule Continuous Deployment D2SI : nous avons un répertoire unique dans Gitlab, dans lequel on a l’application pour le frontal, l’application pour le backend, le gitlab CI.yaml et des scripts qui permettent de construire l’application (build) et de la déployer sur AWS. L’ordonnancement des différentes phases (installation, build, test, release et déploiement) est assuré par le gitlab-ci.yml.

Les builds se font avec maven/gradle install (java) ou yarn install (node.js); le release/déploiement est fait sur AWS, via des scripts lançant des appels aux API AWS (orchestrateur ECS pour les déploiements docker, et ECR, sur lequel sont stockées les images Docker).

Quelle est ta mission dans ce projet ?

Je travaille essentiellement au support des équipes de développement sur la chaîne d’intégration et déploiement continus. En premier lieu, il s’agit de présenter la solution de CI aux équipes de développement : quelle arborescence est mise en place, comment fonctionne la chaîne, et quel est le périmètre des développeurs. Il est essentiel de bien faire comprendre la logique de branche (branches d’intégration,de qualification, de staging…) utilisée pour pousser les applications jusqu’à la production. Par exemple, après avoir développé une feature en local, le développeur la déploie sur la branche intégration. A partir de là, le déploiement se fait sur l’environnement d’intégration et le développeur peut voir sa fonction déployée de façon unitaire.

La branche qualification permet de merger l’ensemble des features faites sur l’intégration pour les tester sur l’environnement de qualification. Enfin, on a la branche master, la plus stable, sur laquelle l’application est fonctionnelle. Les images générées par cette branche sont utilisées en production. La particularité de ce projet est que la production est on premise, donc il faut aussi accompagner les équipes sur les process de déploiement on premise basés sur des outils “maisons”. Le déploiement on premise consiste à récupérer les images Docker générées sur la branche Master et de les lancer sur les infrastructures internes. Il n’y a pas de build effectué on premise.

Pour résumer, ma mission consiste donc à accompagner les équipes de développement sur le fonctionnement de cette chaîne CI, à en améliorer la partie scripts et déploiement, et à faciliter la communication pour les passages en production.

Comment s’est passé l’accompagnement des équipes de développement ?

J’ai essentiellement acquis mon expérience sur des productions en environnements Windows, donc avec une forte orientation système. Comme je n’ai pas de background en développement, c’était un peu compliqué au début… Les gitflow et la logique de branche peuvent aller à l’encontre des habitudes de travail des développeurs, donc il faut prendre le temps d’expliquer et de passer en revue toutes les notions nécessaires. Toutes les équipes ne suivent pas : certains utilisent uniquement la branche master et pas la branche d’intégration. Si ensuite on a un problème sur une branche, c’est plus compliqué de revenir en arrière. Il y a donc un fort enjeu de communication, parce qu’on donne des recommandations, mais rien n’oblige les développeurs à les suivre.

Quelles améliorations ont été apportées ?

Nous avons amélioré la logique de déploiement en réduisant le nombre de phases à 3: build, test, déploiement. Les scripts sont maintenant embarqués dans le fichier gitlab-ci.yml qui est templatisé pour faciliter les mises à jour des scripts de déploiement et notre travail avec les développeurs. Les environnements Gitlab-ci nous permettent de surcharger des variables par environnements ce qui nous permet d’être plus flexibles et de donner aux équipes de développement une meilleure visualisation de ce qui se fait. Et de les sensibiliser à la mécanique de déploiement, sur laquelle ils sont amenés à travailler quand ils veulent ajouter un conteneur, ou faire d’autres modifications. Ils peuvent prendre la main sur le fichier yaml utilisé pour lancer les différentes exécutions dans la chaîne pour comprendre ce qui se passe.

Et du point de vue de l’industrialisation ?

Au départ, comme il n’y avait pas de process établi, nous étions très réactifs sur les demandes des développeurs. Mais aller vite a pour conséquence de créer de la dette technique, parce que dans ce cas tout n’est pas conçu pour être industrialisé. Depuis quelques mois donc, nous avons commencé à industrialiser le processus : faire des template, des scripts de déploiement pour automatiser, et créer un cadre autour du déploiement applicatif. Nous avons proposé aux équipes un ensemble d’applications qui sont standard, sur lequel le processus d’industrialisation est rôdé. Si une demande sort de ce cadre standard, on la challenge : est-ce indispensable d’utiliser MongoDB plutôt que PostgreSQL ? Mais nous avons aussi quelques applications qui sortent de ce standard.

Comment est-ce que ton expérience de la production t’aide dans ta mission ?

Cela m’a permis d’amener un peu de process. J’ai commencé par faire de la documentation…nous faisions beaucoup de choses, mais ce n’était pas documenté : comment déclarer un nouvel utilisateur, comment déployer une application. Puis, comme il était fréquent de faire plusieurs déploiements dans la journée, j’ai scripté le déploiement des environnements applicatifs (infrastructure sur AWS) et la mise à disposition du répertoire projet sous Gitlab avec les fichiers initialisés,de façon à ce la mise en place d’un nouveau projet soit automatisé. Deux scripts permettent d’initier un projet: après avoir renseigné les informations nécessaires, le script de création de projet sous Gitlab lance les séquences, clone le repository, modifie les variables, créer le répertoire gitlab pour le nouveau projet avec un template prêt à être déployé. Cela m’a permis de gagner du temps, et cela permet aux développeurs d’avoir leur projet visible sur Gitlab. Les environnements sont crées de la même manière en lançant un script permettant de séquencer nos différents fichiers Terraform. Je fais évoluer ces scripts en fonction des nouveaux services qui sont mis à disposition. Par exemple, on a ajouté du stockage (S3), du mail (SES). Le bucket S3 est déployé de base, mais le mail est optionnel.

Quelles découvertes as-tu faites au niveau technologique ?

Je viens d’un environnement Windows, je suis maintenant sur un poste Linux. Bash, Git, Docker, Amazon ECS…tout cela est nouveau pour moi. Sur Docker, j’ai appris à optimiser les différentes couches applicatives, comment faire un bon dockerfile, quels éléments variabiliser dans la stack… J’ai aussi beaucoup appris coté Gitlab et CI/CD : définir un gitlab-ci.yaml qui soit propre, débugguer pour les équipes applicatives. Et sur AWS, j’ai beaucoup évolué sur l’infrastructure as code, et Terraform que j’utilise régulièrement pour construire les environnements applicatifs: DNS, ECS, RDS, S3… c’est tout nouveau, donc très intéressant.

Comment se passe le travail dans la cellule CI/CD ?

Nous partageons beaucoup de sujets, je peux discuter de mes problématiques avec mes collègues. Nous avons aussi beaucoup d’échanges sur le channel CI/CD sur Slack, par exemple récemment j’ai eu un problème de conteneurs java out of memory, j’ai tout de suite eu une réponse d’un consultant plus expérimenté. En cas de galère, il y a toujours un point de contact disponible dans la cellule ! Et quand je suis arrivé dans la cellule, je n’avais jamais fait de CI/CD : j’ai été très bien accompagné, j’ai pu monter en compétence et découvrir de nouveaux sujets.