Découvrez les retours d’expérience de Mohammed autour des enjeux et bonnes pratiques liés à l’intégration continue

Mohammed est ingénieur de conception et développement chez Infogene et capitalise plus de 10 ans d’expérience dans l’IT avec une spécialisation dans les projets e-commerce en particulier Magento. Il travaille également au sein du Centre de Services de Paris sur des missions clients variées, principalement au forfait.

Dans cette interview, il nous partage sa vision pragmatique de l’intégration continue et ses convictions consolidées au travers de ses nombreux retours d’expérience projets.

‍

‍

Pourrais-tu nous donner ta définition, aussi concrète que possible, de l’intégration continue ?

L’intégration continue, c’est un process qui fait partie du DevOps. L’idée générale est d’automatiser une part importante des tâches fastidieuses réalisées par les développeurs et les opérationnels, donc de gagner énormément de temps. Mais pas uniquement !

Pour illustrer, quand un développeur a finalisé son code source, il doit mener de nombreux tests avant un possible passage en production. Ces tests sont souvent faits manuellement : éviter les régressions, les bugs… Tout ce qui est nécessaire pour garantir la qualité du code. L'automatisation de cette tâche permettra un gain de temps et un niveau de qualité supérieure.

Pour donner une vision synthétique, l’intégration continue intervient sur plusieurs étapes. Premièrement, le partage du code source dans le référentiel centralisé ou logiciel de gestion des versions, Git par exemple. Ensuite, le développeur doit s’assurer que cette fonctionnalité soit opérationnelle, c’est l’étape de BUILD ou construction, qui nécessite d’exécuter plusieurs scripts de tests unitaires et fonctionnels. Il faut bien sûr vérifier que le nouveau code s’intègre dans les briques existantes, le « merger » ! Pour finir, c’est la publication du code source final et validé, considéré comme potentiellement déployable sur l’environnement de production.

Fait manuellement, 25% du temps de développement est dédié au test. Cette écriture des tests est particulièrement fastidieuse !

Dans une équipe de dix développeurs, chacun va développer sa fonctionnalité et ses tests. À chaque ajout de fonctionnalité, il doit exécuter tous les tests précédents. Fait manuellement, cela prend un temps énorme ! Plus l’équipe grandit et le produit se complexifie, plus cette tâche devient chronophage.

Configurer et mettre en place un pipeline d’intégration continue apporte la réponse à ces problématiques récurrentes : automatiser et rendre plus efficaces ces étapes manuelles. L’intégration continue prend le code source d’une nouvelle fonctionnalité, va le « construire », réaliser les tests et la publier.

‍

‍

Il existe plusieurs terminologies autour de cette notion de continuité : intégration continue, déploiement continu, distribution continue… Comment les positionnes-tu les unes par rapport aux autres ?

Avant tout, mettons en lumière un abus de langage : souvent, quand on parle d’intégration continue, on pense à l’ensemble de la chaîne, jusqu’au déploiement. Dans la réalité, l’intégration continue s’arrête à la phase Build. C’est pour cela qu’on parle de CI/CD.

Tout ces sujets sont bien sûr étroitement liés, mais correspondent à des périmètres différents. Comprendre ces différences, c’est aussi comprendre le cycle global, et les différents paliers d’efficacité que l’on peut franchir !

La distribution continue ou continuous distribution, peut être assimilée à la publication du code vers toutes les équipes, y compris vers les opérationnels. On annonce en quelque sorte qu’on a une version de code testée, validée, prête à être déployée et qui sert de référence ! Au sein des équipes de développement, lorsqu’on développe une fonctionnalité, on part d’une des versions du code. Définir cette version de référence est essentiel : il faut homogénéiser pour toutes les parties prenantes et répondre ainsi à un certain nombre de standards suivant les langages utilisés comme PSR PHP Standard Recommendation qui est un ensemble de recommandations pour la programmation PHP.

Le déploiement continu, c’est le Graal ! Cela signifie que tout le process est automatisé de bout en bout : build, test, merge, publication dans le référentiel et déploiement en production.

Cependant, pour arriver à cette maturité, beaucoup d’efforts doivent être menés sur le Build et les tests. Chaque développement doit être conçu comme une brique testable à quasiment 100%. Il faut également tester au fur et à mesure, en commençant par les premières étapes, tout le process.

Pour mettre en place le déploiement continu, la complexité ne repose pas sur la bascule du manuel à l’automatique, mais sur le fait d’avoir 100% confiance dans tout le pipeline d’intégration continue en amont.

C’est pourquoi, ma conviction, c’est qu’on ne peut pas commencer un projet en déploiement continu sans mettre auparavant la démarche à l’épreuve. On teste, on reteste, on vérifie que chaque étape d’automatisation ne génère pas de problèmes, et ensuite, seulement, on fait confiance à notre pipeline d’intégration continue. Si en retestant manuellement les étapes automatisées à plusieurs reprises, on n’identifie pas de bug, alors on peut aller vers le déploiement continu. Pour atteindre cette maturité, il faut construire et vérifier par palier !

Garantir la qualité avec un minimum d’effort, se concentrer sur le développement et accélérer le Time-To-Market des fonctionnalités, c’est la promesse du CI/CD !

‍

Quels sont les prérequis en termes d’organisation et d’outils pour mettre en place une démarche d’intégration continue ?

Posons déjà un constat : on ne peut pas mettre en place une chaîne d’intégration continue si l’organisation n’a pas déjà fait un pas vers les méthodes agiles. L’intégration continue a été introduite par la démarche DevOps, qui s’inspire elle-même des méthodologies Agile et Lean.

Parmi les principes de l’agilité, il y a la mise en œuvre de livraisons rapides reposant sur des cycles courts de quelques semaines, plutôt que des livraisons de packs complets de nombreuses fonctionnalités. Cela requiert que ces incréments soient testables. Le projet est ainsi dispatché en plusieurs sprints sur plusieurs semaines. Des équipes de quelques personnes vont pouvoir travailler sur un incrément de produit qui sera mis en production.

C’est cette accélération et cette multiplication des cycles de livraisons, et donc de tests, de publications etc, qui ont fait naître le besoin d’une chaîne d’intégration et déploiement continu !

L’intégration continue et le déploiement continu permettent d’adopter un rythme de livraison soutenu et soutenable pour toute l’équipe de développement ! Sans automatisation, soutenir la cadence de mise en production n’est pas réaliste pour des projets importants.

Pour conclure sur ce point : si vous êtes déjà dans une démarche agile, vous avez le socle d’organisation pour l’intégration continue, si ce n’est pas le cas, commencez par-là !

En termes d’outils, il en existe de nombreux qui permettent d’aller vers ce process d’intégration continue. Le plus ancien, c’est Jenkins. Son souci, selon moi, c’est qu’il est un peu lourd. Ecrire les configurations de Jenkins pour automatiser tout le processus, c’est assez laborieux… Il est difficile de créer un process d’intégration continue et de le mettre en place rapidement.

Je peux citer CircleCI, une solution SaaS qui permet via APIs de jouer les scripts d’intégration continue ou Travis CI en SaaS également et gratuit pour les projets Open Source. Ma préférence va finalement vers GitLab CI/CD, une fonctionnalité de GitLab qui permet de mettre en place des pipelines de CI/CD pour tous les projets. Nous l’avons installé sur nos serveurs en interne chez Infogene et c’est gratuit. L’avantage est également de disposer ainsi d’un produit complet au sein de Gitlab que nous utilisons également comme hébergeur du code source et comme gestionnaire de versions.

Pour repérer un outil d’intégration continu, il suffit de regarder son nom : dans 90% des cas, il y a CI dedans !

‍

‍

Au niveau des projets IT, quels ont été les impacts de la mise en place de l’approche CI /CD ?  

Quand on commence à travailler de cette manière, on impose un rythme. L’équipe va développer des fonctionnalités en continu et il faut être complètement aligné avec le client. Un investissement des deux côtés est nécessaire afin d’avoir une expression du besoin clair et une vision partagée des attentes et du mode de fonctionnement.

Cette implication du client dans tout le process est similaire à ce qui est attendu dans la méthode agile. Je peux faire toutes les automatisations que je veux, si ma fonctionnalité n’est pas alignée avec les besoins métiers, elle ne verra pas le jour !

C’est la collaboration entre équipes métiers, équipes de développement et équipes opérationnelles qui est le socle pour maîtriser le process agile et l’intégration continue.

Si on s’intéresse plus spécifiquement aux équipes de développement, le premier impact, c’est l’amélioration de la qualité et de l’homogénéité du code ! Finies également les pertes de temps pour se synchroniser et les sollicitations : « j’ai fini ma fonctionnalité, les opérationnels sont-ils libres pour déployer ? ». Avec des livraisons très fréquentes, cela représente un gain d’efficacité énorme.

Côté client, en plus de soutenir cette approche agile, un bénéfice est le time-to-market. Le produit peut évoluer vite et on gagne en réactivité. Si c’est utile en début de projet, c’est aussi évident dans les projets en TMA (Tierce Maintenance Applicative) : des réponses sont apportées rapidement aux besoins complémentaires qui surgissent sur la solution en production. Dans l’e-commerce, c’est extrêmement utile par exemple !

Ces bénéfices en qualité, temps et budget, sont avant tout perceptibles sur des projets de taille importante. Plus un projet grossit en termes d’équipes et de périmètre fonctionnel, plus l’automatisation apporte un fort retour sur investissement : la probabilité de générer des bugs et le volume d’interactions et de tâches manuelles explosent !

Beaucoup d’entreprises ne perçoivent ainsi pas l’intérêt de la philosophie DevOps en début de projet. Une fois que le projet s’est complexifié, les bugs commencent alors à pousser comme des champignons sur les tableaux de bord des systèmes de suivi des bugs et tout le monde commence à s’intéresser au sujet de l’intégration continue !

‍

‍

Comment adaptez-vous votre démarche d’intégration continue aux spécificités des différents clients avec qui vous travaillez ?

Ce mouvement DevOps et agilité a vraiment commencé à bouger ces dernières années. Il y a encore 5 ans, très peu de clients percevaient les bienfaits de l’agilité et de l’intégration continue.

Si l’intégration continue a pris de la maturité ces dernières années, il y a toujours des entreprises qui sont réticentes et sont plus rassurées par des méthodes plus traditionnelles. Développer au fil de l’eau, cela permet d’adapter le besoin en cours de route, mais cela nécessite en contrepartie une collaboration de proximité entre le client et nos équipes de développement. De même, si le client est déjà engagé sur des dates et un périmètre fonctionnel très précis, la méthodologie agile n’est pas la plus adéquate.

Ce n’est donc pas toujours une évidence et il faut savoir ajuster la méthode selon chaque client ! Par exemple, si le client n’est pas prêt pour mettre en place un cycle d’intégration continue complet, on peut adapter la couverture et la focaliser sur l’automatisation des tests unitaires. C’est déjà une optimisation conséquente en termes de temps et de qualité.

Certains bugs sont facilement identifiables et corrigibles, et des erreurs humaines arrivent forcément : on applique en quelque sorte la loi de Pareto au cycle d’intégration continue !

Au sein du Centre de Services de Paris, nous avons l’organisation, les outils, et les équipes pour couvrir tout le cycle de l’intégration et du déploiement continu. Nous savons la capacité d'utiliser uniquement certaines facettes selon les projets, les besoins et les attentes des clients. Quand on s’intéresse à l’agilité, il faut aussi savoir être agile !