Automatisation du cycle DevOps : comment garder le contrôle

Approche atomique ou systémique ?

Il existe deux grands paradigmes de l’automatisation DevOps. L’approche atomique consiste à développer et déployer des applications entières qui partagent relativement peu de composants et qui reposent sur une structure monolithique. Les phases du projet sont distinctes et il est possible – voire conseillé – de traiter individuellement l’automatisation des tâches à chaque phase du cycle. Dans les applications de cloud hybride, le back-end ou la partie centrale du traitement des transactions d’une application est souvent développé de manière atomique.

L’automatisation systémique cible les trois ou quatre dernières phases du cycle DevOps et crée un pipeline de développement. Avec l’automatisation systémique, les outils et les procédures de chaque phase se connectent de manière transparente aux autres phases. Par conséquent, cette approche unificatrice englobe des pratiques telles que le développement rapide, le développement agile ou l’intégration continue/déploiement continu (CI/CD).

La plupart des équipes qui adoptent l’approche systémique développent des applications subdivisées en composants, correspondant généralement à des microservices. Dans ces environnements, le code est très régulièrement modifié, les composants sont partagés entre plusieurs applications et les développements ont lieu en parallèle. Les outils qui couvrent l’ensemble des phases ciblées sont les meilleurs. Il faut donc rechercher des packages qui utilisent ces caractérisations unificatrices pour décrire leur champ d’application. Enfin, n’utilisez pas l’automatisation systémique là où elle n’a pas sa place, elle ajouterait de la complexité.

IA et DevOps : la place des outils d’assistance au développement

L’élément minimal nécessaire pour intégrer un outil automatisé dans un flux de travail est un dépôt, un référentiel envisagé comme l’unique source de vérité. GitHub et GitLab sont des outils populaires qui servent de point d’intégration pour les cinq phases DevOps et relient les tâches entre elles. À partir d’un dépôt Git, les équipes peuvent lancer des stratégies d’automatisation pour chaque phase et faciliter l’intégration entre les phases.

Plus récemment, les équipes IT automatisent le développement de programmes en assignant aux outils d’IA des tâches de routine, telles que l’assistance aux membres juniors de l’équipe, la révision du code et la rédaction d’appels d’API. GitHub Copilot est un outil qui peut suggérer du code en fonction du contexte et des pratiques apprises. Parmi les autres outils, citons ClickUp, qui offre également des fonctions de gestion de projet, CodeT5, Codex d’OpenAI, ainsi que Tabnine et Codiga qui permettent tous deux d’examiner le code.

Les outils d’IA générant du code peuvent commettre des erreurs. Leur production doit donc être soumise à un examen humain rigoureux. S’il est tentant de confier à un autre outil automatique la détection de la présence de bugs dans ce code synthétique, les entreprises sont prévenues qu’une telle pratique réclame – si elle n’est pas prohibée – une supervision humaine.

Bien que ces outils prennent en charge une douzaine de langages de programmation, ils couvrent plus ou moins bien leurs spécificités. Les équipes responsables d’application monolingue devront donc s’atteler à trouver le meilleur candidat parmi un large panel de solutions.

Les outils pour automatiser les étapes de construction, de test et de déploiement

Bien qu’il soit possible d’automatiser les phases de compilation, de test et de déploiement de manière atomique, la plupart des utilisateurs considèrent ces trois phases comme une seule et même étape, lorsqu’ils envisagent l’automatisation DevOps. Les produits de tests automatisés se sont développés pour inclure l’automatisation du build et du déploiement. Des outils populaires comme Jira et Jenkins prennent désormais en charge les trois phases.

De toutes les étapes du cycle DevOps, c’est celle du test qui est historiquement la plus automatisée. L’outil de test Selenium est bien adapté à l’automatisation atomique et systémique, car il s’intègre bien avec les autres briques constituant la chaîne de construction/test/déploiement. Appium est un autre outil similaire, particulièrement utile pour le développement multiplateforme. Bon nombre de ces logiciels d’automatisation des tests, comme Selenium, intègrent dorénavant l’IA, ce qui s’avère pratique pour la génération de tests unitaires.

Les tests automatisés peuvent poser deux problèmes. Le premier est qu’ils peuvent générer des tests redondants et, par conséquent, manquer des conditions essentielles à la validité des données. Cela peut se produire lorsque les développeurs ne parviennent pas à inclure dans le code les API/hooks de test appropriés pour guider la génération des données synthétiques. Un architecte applicatif devrait travailler avec l’équipe responsable de l’élaboration des tests afin d’assurer leur optimisation.

Deuxième problème, souvent les équipes ne maintiennent pas et ne mettent pas à jour les ancres (hooks) de génération de données de test au fur et à mesure des changements au sein d’une application. Les équipes peuvent résoudre ce problème en faisant des mises à jour de la génération des données de test, une partie spécifique de tout projet impliquant des modifications du logiciel actuel ou des ajouts ayant un impact sur la fonctionnalité.

Concernant l’automatisation du déploiement, il existe plusieurs options. Celles-ci peuvent être combinées et s’adaptent aussi bien aux environnements sur site que dans le cloud. Kubernetes s’est imposé comme la pièce maîtresse de la gestion de conteneurs Docker, d’autant que leur déploiement peut être piloté depuis des dépôts Git. Les outils de gestion de configuration, dont Ansible, Chef ou Puppet ne disparaissent pas. Par ailleurs, les outils d’Infrastructure as code, tels Terraform ou Pulumi, ont fortement gagné en traction, que ce soit dans des environnements reposant sur Kubernetes ou sur des machines virtuelles.

Automatisation DevOps : bien gérer les risques grandissants

L’automatisation du cycle DevOps n’est pas sans risque. Les équipes informatiques qui abordent ces quatre points peuvent atténuer les compromis potentiels d’une automatisation accrue.

Peur de la complexité

De nombreuses entreprises pensent que l’adoption de l’automatisation DevOps est complexe. Le flux de travail qui en résulte semble plus compliqué qu’il ne l’était auparavant. Il faut effectivement une planification approfondie et un certain recyclage pour exploiter pleinement l’automatisation DevOps. Une préparation à la hâte et une mauvaise exécution peuvent engendrer des complications. Mais avec la discipline appropriée, l’automatisation DevOps réduira la complexité.

Sécurité des applications

Le maintien de la sécurité lors de l’automatisation d’un cycle DevOps variera d’une phase à l’autre. L’objectif de haut niveau est de protéger les logiciels en sécurisant l’accès au code et aux builds. Les équipes peuvent y parvenir en contrôlant l’accès au dépôt Git et en gérant les droits pull/push. Lorsque les outils d’automatisation du développement suggèrent des packages ou des librairies, les équipes doivent les gérer afin de s’assurer qu’une librairie recommandée n’est pas compromise. Cet aspect, souvent négligé, l’est encore davantage lorsque l’IA suggère du code.

Code contaminé

L’automatisation peut augmenter le risque d’introduire du code contaminé – y compris des éléments en provenance de librairies tierces et des composants développés par l’utilisateur lui-même – lors de la phase de compilation. L’automatisation du build peut masquer les détails de l’assemblage du logiciel pour les tests et le déploiement, ce qui augmente le risque de substituer des logiciels malveillants à des composants logiciels légitimes. L’automatisation de la construction devrait puiser le code dans le référentiel, qui devrait utiliser une technologie de sécurité d’accès pour gérer les versions et l’intégrité.

Perte de conscience humaine

Lorsque de nombreuses tâches du cycle DevOps sont automatisées, la supervision humaine s’en trouve compliquée. L’équipe DevOps s’habitue à ce que les outils prennent des décisions et perd conscience du flux de travail qui sous-tend l’ensemble de la chaîne CI/CD. La dernière étape de tout projet d’automatisation DevOps devrait consister à parcourir l’ensemble du flux du projet afin d’évaluer où la revue par des professionnels devrait intervenir. Les équipes doivent s’assurer que les informations disponibles à toutes les étapes satisfont aux exigences de la révision.