Les avantages et les inconvénients des pipelines CI/CD
De nombreuses entreprises commencent leur parcours DevOps par un pipeline de développement et de livraison continus. Avant de vous lancer, comprenez les avantages et inconvénients fondamentaux des pipelines CI/CD.
L’intégration et la livraison continues sont au cœur de la stratégie DevOps. Avec l’intégration continue, les équipes mettent à jour et réintroduisent fréquemment du code, tandis qu’avec la livraison continue, elles appliquent des tests supplémentaires pour s’assurer que le code est prêt à être validé pour le déploiement. Une fois combinées, ces deux techniques permettent d’améliorer régulièrement l’environnement DevOps et de répondre plus rapidement aux besoins de l’entreprise et des utilisateurs. Le CI/CD se distingue clairement de l’approche Waterfall, qui implique des changements importants à des intervalles souvent très éloignés des uns des autres.
De manière générale, l’adoption de la méthode CI/CD semble parfaitement logique : les développeurs hiérarchisent les demandes de l’organisation sous forme de modifications dissociées et les transfèrent au plus vite à l’environnement opérationnel, en initiant en place des contrôles et des équilibres suffisants pour assurer une transition en douceur. Cependant, une DSI doit tenir compte de plusieurs aspects avant d’embrasser une telle approche.
Quels sont les avantages d’un environnement CI/CD ?
Examinons les principaux avantages d’un processus CI/CD.
- Un développement plus réactif. De nombreuses entreprises qui s’efforcent de livrer et de fonctionner en temps réel sont souvent gênées par la lenteur du développement traditionnel des applications. Avec le CI/CD, les programmeurs peuvent rapidement établir des priorités et répondre à chaque besoin organisationnel. Cela nécessite également une relation étroite avec les dirigeants afin de privilégier les domaines ayant le plus grand retentissement potentiel sur l’entreprise, plutôt que de laisser les développeurs se concentrer sur les aspects les plus techniques.
- Une meilleure qualité du code. Les petites modifications impliquent moins de code, et sa qualité peut être vérifiée dans une plus large mesure avant qu’il n’atteigne un environnement de test complet. Les développeurs peuvent plus facilement identifier et résoudre les problèmes à un stade plus avancé dans le processus DevOps. La qualité du code reste cependant importante : le CI/CD ne signifie pas que vous pouvez faire des économies au nom de la rapidité.
- Des cycles de test plus courts. Des volumes de code moins complexes et moins importants à vérifier permet de réduire le nombre de tests de fonctionnalités tout au long du processus CI/CD. Cette étape n’est plus aussi stricte qu’auparavant (bien qu’il faille maintenir tous les garde-fous en ce qui concerne la sécurité). Les nouvelles possibilités créées par la communauté des développeurs sont intégrées à l’environnement opérationnel beaucoup plus rapidement qu’avec les rétrotests complets des changements massifs. Encore une fois, cela ne signifie pas que vous devez prendre des raccourcis en matière de tests, mais seulement qu’une approche CI/CD bien menée implique moins d’interactions entre ce qui est modifié et ce qui reste inchangé.
- Un suivi facilité des changements dans l’environnement opérationnel. Si un problème survient au cours d’un déploiement, il est généralement beaucoup plus facile d’en identifier la cause profonde lorsqu’il ne s’agit que d’un ou deux changements. Toutefois, les bons outils doivent être mis en place pour garantir que le suivi est suffisant et efficace.
- Un rollback moins douloureux, si nécessaire. Si la plateforme doit revenir à une position antérieure connue, de plus petites modifications impliquent moins d’efforts pour effectuer le rollback. Là encore, il faut s’assurer d’avoir les bons instruments, en particulier un outil d’orchestration efficace.
Quels sont les inconvénients d’un environnement CI/CD ?
L’approche CI/CD présente plusieurs difficultés que vous devez résoudre.
- Tout le monde n’apprécie pas le changement continu. De nombreuses mises à jour opérées depuis la stack CI/CD, tels ceux concernant les bases de données back-end ou les processus métier, sont invisibles pour l’usager. D’autres ont un impact sur l’interface utilisateur, comme le renommage de fonctions, le déplacement des éléments de la barre de menu et les modifications apportées aux processus établis. Les utilisateurs ne les apprécieront pas forcément. Toute volonté de changement de l’UI doit être communiquée le plus tôt possible aux usagers. Dans la mesure du possible, elle doit s’accompagner d’une notification et d’un rapide tutoriel, à l’écran. Avec le développement en cascade, une organisation peut former le service d’assistance (ainsi que les utilisateurs) sur tous les changements à venir. Impliquez le service d’assistance dans le processus global de CI/CD et laissez le personnel voir et donner leur avis sur les évolutions avant qu’elles ne soient mises en ligne.
- Les effets domino de l’approche CI/CD dans un environnement de microservices. Une petite modification peut avoir une répercussion sur plusieurs interactions distinctes. La révision d’un microservice peut se produire sans accroc, mais elle peut causer des problèmes dans d’autres chaînes de services. La gestion de la configuration permet de suivre toutes les dépendances entre les différents microservices, et l’orchestration peut alors contribuer à garantir qu’un changement n’a pas d’impact sur d’autres combinaisons d’assets et que les équipes de développement peuvent annuler les changements si nécessaire.
- Qui dit changement continu dit surveillance permanente. Les changements CI/CD, de par leur nature, ont un impact sur la plateforme sur laquelle ils sont déployés. La surveillance et le reporting en temps réel sont indispensables pour comprendre et résoudre rapidement toute difficulté. Si un bout de code se comporte mal, vous devez le savoir immédiatement, avant que les erreurs ne se propagent à d’autres services et que les plaintes des usagers ne submergent le support.
- La gestion des ressources doit être réactive. En l’absence de tests approfondis préalables, les développeurs et les testeurs peuvent ne pas anticiper les répercussions sur les ressources et les performances d’un changement CI/CD avant son déploiement. Pour éviter les surconsommations imprévues, il faut automatiser autant que possible la préparation et le provisionnement des workloads de manière agnostique, en utilisant des recettes et des manifestes qui définissent comment pousser les charges de travail vers les plateformes de l’organisation. Là encore, les outils d’orchestration peuvent aider à surveiller en permanence ce qui se passe sur les infrastructures IT et à prendre des mesures correctives : affecter davantage de ressources (calcul ou mémoire), limiter l’activité, réaffecter, lancer ou arrêter une instance du microservice ou de l’application, ou encore déclencher une intervention manuelle.
Le CI/CD est-il adapté à votre entreprise ?
Le CI/CD, tout comme le DevOps dans son ensemble, ne peut être considéré comme un simple processus à sens unique allant de l’entreprise aux opérations en passant par le développement. À chaque étape, des boucles de rétroaction doivent être en place pour vérifier :
Le changement demandé est-il techniquement réalisable ? Est-il rentable au stade du développement ?
- La modification nécessitera-t-elle un investissement matériel plus important afin de combler les besoins en ressources de calcul ?
- Les utilisateurs sont-ils satisfaits du résultat des changements ou existe-t-il des ajustements simples, qui amélioreraient l’efficacité ou l’acceptation de la nouvelle fonctionnalité ?
- Le service d’assistance peut-il fournir un retour d’information efficace aux développeurs, et à l’entreprise, sur l’efficacité du changement ?
Le CI/CD peut modifier la façon dont l’IT soutient l’entreprise en apportant des évolutions beaucoup plus rapides et plus efficientes à un environnement. Cependant, il ne s’agit pas d’une solution miracle ; il faut l’incorporer et l’utiliser avec soin, l’adapter à vos technologies et vos besoins, sinon il introduira une nouvelle couche de chaos. D’autant que certains progiciels et certaines plateformes font du CI/CD un prérequis, intimant une mutation organisationnelle non négligeable.