Dans le cadre de mon alternance à IN'TECH, j'ai rejoint l'équipe LTelecom dans l'entreprise Infomil. L'équipe, composée de 9 personnes, s'occupe principalement du développement du site internet Réglomobile, la marque de forfaits téléphoniques de E.Leclerc.
Nous travaillons avec la méthode Agile Scrum, ce qui m'a permis de me former encore plus sur le sujet en parallèle.
La mission principale de mon alternance était centrée sur l'Intégration Continue (IC) et son amélioration.
L'Intégration Continue est un ensemble de pratiques permettant l'ajout automatique de tous les développements en vérifiant qu'ils soient fonctionnels et ne cassent pas l'application, et ce plusieurs fois par jour.
Pour résumer les étapes, comme on peut le voir sur le schéma ci-dessous, les développeurs poussent des modifications au code source. Le système d’IC réalise ensuite un build du code source, suivi de l'exécution de tests automatiques. Il produit ensuite un résultat qui va être remonté aux développeurs afin qu’ils puissent corriger les éventuelles erreurs ou sinon déployer le code dans l’environnement souhaité.
Nous avons besoin de l'intégration continue dans l’entreprise afin de réduire le temps passé à vérifier que le projet est toujours fonctionnel et à tester les modifications implémentées. Notre outil d’IC a été créé à la main et est maintenu par l'équipe dans laquelle je travaille. La maintenance inclut des modifications et ajouts de fonctionnalités dans l’outil mais aussi la correction d'éventuels bugs ou l'amélioration de ce dernier.
Étant mon sujet principal d'alternance, j'ai pu toucher à plusieurs parties de cette Intégration Continue. Je me suis occupé de faire la compilation et le déploiement automatique d'un nouveau site en .NET Core, framework qui n'avait jamais été ajouté à notre outil, mais aussi paramétrer des nouveaux postes pour l'IC ou encore rajouter des nouvelles fonctionnalités à l'outil.
Pour la compilation du projet en .NET Core, j'ai dû faire en sorte que tous les composants soient bien packagés afin de pouvoir livrer le projet et toutes ses dépendances. J'ai ensuite dû mettre en œuvre l'intégration de la livraison automatique du projet dans notre cycle d'intégration.
Une des difficultés rencontrées lors de ce développement fut la compatibilité des frameworks entre le .NET Core et notre outil qui ne prenait en compte que le .NET Framework jusque-là.
Le problème était que l'API de compilation que nous utilisions n'était pas compatible avec le .NET Core car trop vieille et plus maintenue par Microsoft.
Avec l'aide de mon chef d'équipe, nous avons pu faire en sorte que ce problème soit résolu en changeant l'API utilisée pour la compilation des projets .NET Core.
Au début de nos recherches, nous avons essayé de persévérer avec ce que nous avions déjà en place, afin de ne pas avoir à modifier l'outil en lui-même.
Mais après plusieurs jours de différents tests et modifications mineures, aucune solution ne semblait fonctionner. Nous avons donc décider de passer à l'étape supérieure en utilisant l'API MsBuild, ce qui nous a coûté de faire plus de modifications que l'on aurait aimé.
J'ai pu aussi configurer plusieurs nouveaux postes pour l'IC. Nous utilisons des PC dit "agents" qui sont des postes utilisés uniquement pour notre intégration continue.
Pour la configuration de ces postes, il faut que notre gestionnaire de sources soit configuré correctement pour pouvoir récupérer les sources et compiler les projets pour les livrer ensuite. Il faut aussi que notre outil soit correctement installé sur le PC afin de lire notre base de données dans laquelle on stocke les exécutions faites ou à faire pour l'IC.
Pour respecter ces différentes conditions, j'ai dû créer et configurer un workspace générique sur chacun des agents sur Perforce, notre gestionnaire de source.
J'ai dû le configurer de manière à ce qu'il récupère les sources dont nous avons besoin, mais aussi de manière à ce que tout le monde y ait accès, afin de pouvoir faire des corrections ou modifications de paramétrage si besoin.
L'installation de notre outil d'IC sur ces agents n'était pas très compliqué. Je me suis inspiré de procédures que nous avions déjà développées pour un ancien agent, qui était déjà configuré avant mon arrivée dans l'entreprise.
J'ai aussi eu à ajouter une fonctionnalité à l'outil permettant de rajouter une commande pour récupérer la liste de toutes les références d'un projet spécifié.
L'ajout de cette fonctionnalité était assez compliqué. L'outil est extrêmement dense et complexe, et plonger dedans plus en détail a été une bonne découverte mais m'a aussi pris du temps.
Il m'a fallu suivre une documentation décrivant de manière très succincte comment rajouter une action dans l'outil (document visible ici).
J'ai rajouté une classe dans le namespace "Packaging". Cette classe est générée automatiquement à l'aide du text templating (ou tt).
Le tt permet de générer des fichiers à l'aide d'une définition d'un template et de données inscrites dans un fichier référentiel, qui est ici un fichier au format XML.
J'ai donc dû concevoir mon action pour définir les attributs dont elle allait avoir besoin, en plus du type de ces derniers. J'ai ensuite modifié d'autres fichiers XML utilisant du tt pour permettre la sérialisation et desérialisation entre mon action et les procédures au format XML qui l'utilisent.
Les dernières modifications à faire sont dans un fichier XSD. Le fichier XSD permet de rajouter une vérification et une auto-complétion sur l'écriture de la procédure XML, pour être sûr de rentrer les bonnes valeurs et de ne pas en oublier.
J'ai eu un blocage sur la partie de text templating et de génération du code, car c'était quelque chose de nouveau pour moi, et le document ne décrivait pas assez bien le déroulé du développement.
J'ai été aidé de mon chef d'équipe sur cette partie-là, et une fois comprise, j'ai modifié la documentation afin d'éviter un blocage dans le futur.
On peut voir ici une partie de la classe qui est générée par le text templating. Il a notamment généré la méthode Traiter avec ses paramètres. Je me suis ensuite occupé de la remplir afin que mon action appelle la méthode que j’ai développée ci-dessous, qui correspond à ce que va réellement faire la fonctionnalité.
Ici, nous avons à gauche la première partie, qui va faire des vérifications à la ligne 2498 afin de s’assurer que le chemin vers les projets indiqué dans la procédure XML existe bien. Il va ensuite appeler pGetProjetsDansRepertoire (image de droite), qui va récupérer la liste de tous les projets qu’il trouve et indiquer leur type (projets VB.NET ou C#). Ensuite on revient dans notre première méthode à gauche, et la liste des projets que nous avons récupérée est ajoutée à une liste qui sera ensuite triée et mise dans le fichier indiqué dans "cheminResultat" dans la procédure XML.
Les développements que j’ai pu mener sur l’outil d'Intégration Continue ont permis de rendre le système plus robuste et d’aider à l’améliorer. Je vais aussi continuer à maintenir l’outil et rajouter des fonctionnalités selon les besoins qui surviendront dans le futur.
Je trouve l'Intégration Continue et les développements que j'ai pu faire très intéressants et très enrichissants. Ces travaux m'ont permis de monter en compétence et de mieux comprendre les enjeux de l'IC dans un projet.
Grâce à tout ça, l’Intégration Continue est une spécialité que j’envisage pour mon projet professionnel.
Mon chef de projet m'a fait part de son contentement vis-à-vis de ces développements, ce qui a renforcé ma confiance en moi sur mes capacités à appréhender un sujet complexe et à le mener à bout.