Interview : comment l’intégration continue permet d’identifier les problèmes d’intégration le plus tôt possible dans les cycles de développement.
Pourquoi adopter l’intégration continue ?
Le principe de l’intégration continue vise à identifier des problèmes d’intégration le plus tôt possible dans les cycles de développement. Lors du développement d’une fonctionnalité, son développeur écrit également un test qui lui est associé. Un serveur d’intégration va ensuite lancer ce test pour s’assurer qu’aucune régression n’a été injectée dans le code source. Si aucune erreur n’est trouvée, le serveur d’intégration déploie le code en production. Dans le cas contraire le déploiement est arrêté et le développeur alerté. David Michel, spécialiste DevOps, nous dévoile les avantages de cette démarche contribuant à l’état d’esprit Devops.
Pouvez-vous nous donner votre vision de l’intégration continue ?
L’intégration continue permet d’avoir un environnement de référence pour les développeurs. Ils peuvent ainsi générer un binaire de manière reproductible et sécurisé. C’est également cet environnement qui sera utilisé par la suite pour lancer le binaire en production. Cela permet d’éviter les problèmes lors de la mise en production quand chaque développeur compile de son côté. C’est une recette de cuisine à suivre.
L’autre idée forte dans la notion d’intégration continue, c’est l’automatisation. A la sortie des pipelines de compilation d’une application se trouvent des tests automatiques. Ils peuvent être de différentes natures : unitaires, fonctionnels ou d’intégration. La possibilité de lancer ces tests de façon automatisée, toujours dans un environnement de référence, permet de libérer du temps pour les développeurs. Ce temps gagné servira entre autres à la génération du code. De plus, notre expérience de l’intégration continue nous a amené à inclure des tests de vulnérabilité des dépendances. C’est donc une démarche DevSecOps. Ainsi, grâce à l’automatisation de ces tests dans un environnement de recettes ou de préproduction, toutes les chances sont de notre côté pour que la mise en production se déroule au mieux.
Quel est l’apport de l’infra as a code dans une démarche devops ?
Qui dit automatisation dit écriture d’un code qui soit reproductible. Et dans une démarche d’intégration et de livraison continue, la logique veut que tout devienne code. Concrètement, la technologie permet aujourd’hui d’automatiser la création et la configuration de machines virtuelles (VM) avec du code. L’infra as a code (IaC) permet non seulement de poser un langage commun entre le monde des Devs et des Ops, mais également une utilisation commune. En effet, le langage de développement sera commun, mais aussi les outils. Les Devs vont gagner en connaissance pour pouvoir créer une VM, et les Ops vont connaître l’outillage des Devs. Ce qui va amener à une vraie collaboration. L’IaC permet une vraie démarche DevOps.
Comment aidez-vous les équipes à acquérir un état d’esprit devops ?
Nous essayons de pousser les équipes vers le DevOps, car nous constatons souvent que seuls les développeurs les plus aguerris utilisent les nouvelles technologies qui facilitent la mise en place de l’état d’esprit devops. Dans un premier temps nous ne travaillons que sur la partie Dev, sur les outillages pour l’intégration continue. Mais pour arriver jusqu’au DevOps il faut ajouter la notion d’Agilité. Il faut communiquer et acculturer les différents services pour les convaincre, en embarquant les Ops pour qu’ils s’organisent de la même façon. Il faut leur présenter les nouvelles technologies disponibles et qu’ils en comprennent le bénéfice, leur montrer les apports de l’automatisation. C’est un accompagnement de longue durée. Mais le changement, le déclic, vient souvent de la partie Dev. Le DevOps représente une mentalité que nous essayons de transmettre. C’est avoir conscience que l’équipe partage des connaissances pour améliorer la fiabilisation des déploiements.
Avez-vous identifié des freins dans le déploiement de la démarche devops ?
Quand des responsables Ops ne sont pas encore convaincus, certaines équipes sont bloquées car elles ne disposent pas de leur feu vert. Par exemple un service peut générer la configuration de machines, installer tout l’outillage pour faire du Ansible et être en capacité de déployer de manière automatique… Il faut ensuite coder les scripts qui seront lus par un orchestrateur comme AWX. Mais si les responsables Ops n’ont pas donné leur feu vert pour coder en YAML, utilisé dans Ansible, cela ne sert à rien. Cette peur de perdre le contrôle du côté Ops n’est pas à minimiser. Ce qui semble logique de primes abords, puisqu’un Dev peut cliquer sur un bouton et faire du déploiement. Avec la crainte côté Ops d’une mauvaise utilisation des ressources, et de « casser » une production. Mais cette crainte va à l’encontre du devops, et par extension d’une démarche Agile. Pour acculturer, il faut commencer par une ou deux petites équipes en mode Agile, et trouver les bons sponsors. Cela va servir à montrer les bienfaits de cette démarche, pour pouvoir la généraliser par la suite. Mais cela peut prendre du temps.
La conduite de changement vise donc essentiellement les Ops ?
Non, les Devs également. Les technologies évoluent très vite et il faut continuellement apprendre du nouveau vocabulaire, de nouvelles technologies. Cela demande une véritable ouverture d’esprit, et accepter de régulièrement sortir de sa zone de confort. Tous les profils Devs ne sont pas naturellement enclins à embrasser cette démarche. Mais c’est surtout la charge de travail supplémentaire qui peut rebuter certains développeurs. Car avant cette démarche, les Devs exprimaient des besoins préparés par les Ops. Avec cette démarche devops la responsabilité est partagée. Si un Dev a besoin d’une VM, il doit écrire lui-même un fichier YAML qui va indiquer qu’il lui faut 2 CPU et 3 Go de RAM par exemple. Il doit donc bien appréhender ce dont il a besoin et ce que cela va impliquer. Avec l’intégration continue et le déploiement continu, les deux mondes Dev et Ops doivent trouver leur nouvelle position. Les Devs ne doivent pas avoir l’impression d’être surchargé de travail, et les Ops de perdre une partie de leur travail. Car même si cette démarche donne l’impression que tout est virtuel, il y aura toujours des machines comme socle qu’il faudra configurer, câbler… Et il y aura donc toujours besoin d’une expertise Ops.
Dans une démarche d’intégration et de livraison continue, la logique veut que tout devienne code.
Vous souhaitez échanger avec nos experts autour de vos enjeux et du devops, c’est par ici !