TOOLinux

Le journal du Libre

DevOps : 8 bonnes pratiques d’intégration et de déploiement continus (CI/CD)

samedi 9 novembre 2019

Les entreprises sont de plus en plus nombreuses à adopter les pratiques DevOps, et les pratiques d’intégration continue (CI) et de déploiement continu (CD) sont devenues parties intégrantes du processus de développement de logiciels.

Selon une récente étude IDC, le marché mondial des logiciels DevOps est passé de 2,9 milliards de dollars en 2017 à 5,2 milliards en 2018, et pourrait atteindre 15 milliards de dollars en 2023.

Si votre entreprise a amorcé ou amorce elle aussi une transformation DevOps, sachez qu’il est important de respecter les bonnes pratiques CI/CD pouvant aider à accélérer l’adoption où que vous en soyez du parcours DevOps.

Intégration continue et déploiement continu désignent le processus automatisé de développement et de déploiement de logiciels en cycles courts, selon le modèle build-configuration-déploiement-test-distribution (build-configure-deploy-test-release).

Autrement dit, le processus de CI/CD permet de livrer des logiciels de plus haute qualité fréquemment et de façon prévisible. Reste à respecter un certain nombre de bonnes pratiques pour que la démarche soit pleinement satisfaisante.

8 bonnes pratiques CI/CD pour bien démarrer avec DevOps

Donnez la priorité à la sécurité

On n’accorde jamais trop d’importance aux considérations de sécurité dans un contexte où les failles de sécurité et les vulnérabilités continuent de provoquer des pertes financières massives tout en nuisant à la réputation des entreprises. Comme le système CI/CD donne accès aux bases de code et aux identifiants permettant de déployer dans différents environnements, il est souvent pris comme principale cible des attaques.

Prenons par exemple la fameuse compromission Uber… Des hackers s’étaient procuré les identifiants AWS stockés sur la plateforme GitHub, ce qui leur avait permis de voler les données personnelles de 57 millions d’utilisateurs et 600.000 conducteurs. Les identifiants sont fréquemment stockés dans des référentiels privés à des fins d’automatisation.

Il convient donc d’isoler les systèmes CI/CD et de les placer sur des réseaux internes sécurisés. Les VPN, l’authentification bifactorielle forte et des systèmes de gestion des identités et des accès sont utiles pour appliquer le « principe de moindre privilège » et limiter l’exposition aux menaces. Par exemple, les agents peuvent être mis en conteneur et placés sur des réseaux sécurisés. Par ailleurs, il est important d’intégrer la sécurité dans le processus de développement du début à la fin ; c’est ce qu’on appelle DevSecOps.

Evaluez si votre entreprise est prête pour une architecture microservices

Une architecture microservices est une garantie d’efficacité DevOps. Mais la perspective de revoir l’architecture applicative peut effrayer. Il convient dans ce cas d’envisager une approche incrémentale qui consiste à maintenir les systèmes stratégiques et construire la nouvelle architecture en périphérie. Cette méthode permet de remplacer graduellement l’ancien système par la nouvelle architecture.

Déployez des outils de suivi et de gestion de versions

Les outils comme Jira et Bugzilla peuvent vous apporter plus de visibilité sur l’état d’avancement de vos logiciels et faciliter la collaboration des équipes distribuées. Vous aurez également besoin d’un logiciel de gestion de versions comme Git. En établissant un référentiel unique (ou une « single source of truth ») pour votre équipe, il permet de suivre les changements effectués dans le code source et s’avère essentiel quand il s’agit de faire un saut dans le passé à la faveur d’un rollback. En facilitant la collaboration des équipes et en intégrant les changements dans le dépôt de code partagé, GitOps peut grandement améliorer le MTTR (Mean Time to Recover).

Faites des commits chaque jour et réduisez les branches

La démarche visant à réduire (voire éliminer) les branches s’inscrit dans une volonté de consacrer davantage de temps au développement et moins à la gestion de versions. Mais pour profiter de GitOps au maximum, les développeurs doivent faire des commits directement sur la branche principale ou fusionner les changements émanant des branches locales au moins une fois par jour. Cela revient à gérer l’intégration fréquemment mais par petits bouts au lieu d’être confronté aux difficultés découlant d’une fusion de plusieurs branches effectuée juste avant la sortie de la nouvelle version.

Ne créez qu’un seul build

Eliminez les pratiques qui consistent à effectuer des builds du code source à plusieurs reprises. Que le logiciel doive être compilé, packagé ou intégré à d’autres logiciels, effectuez-le une seule fois et promouvez les binaires. Les implémentations CI les mieux réussies inscrivent le processus de build comme première étape du cycle CI/CD pour packager le logiciel dans un environnement vierge. Ceci réduit la possibilité que des erreurs soient introduites et/ou non détectées ultérieurement. Chaque version de l’artéfact qui en résulte doit être archivée si bien que le build demeure immuable.

Décidez quels processus et tests automatiser en premier

Si une approche incrémentale de l’automatisation paraît justifiée, il s’avère que les entreprises ont souvent de la peine à identifier quels sont les processus manuels qu’il convient d’automatiser en premier. Pour commencer, il convient d’automatiser le processus de compilation du code. Comme les développeurs doivent faire des code commits quotidiennement, il est également judicieux d’automatiser les tests de vérification. Ce sont généralement les tests unitaires qui sont automatisés en premier pour réduire la charge du travail des développeurs.

Ensuite, il est souhaitable d’automatiser les tests fonctionnels, puis les tests d’interface utilisateur (UI). Les tests fonctionnels ne requièrent généralement pas de mises à jour fréquentes du script d’automatisation, contrairement aux tests UI qui induisent des changements plus réguliers. L’idée générale consiste à considérer l’ensemble des dépendances possibles et à évaluer leur impact pour sélectionner judicieusement les priorités d’automatisation.

Distribuez souvent

Les releases fréquentes ne sont possibles que si le logiciel est prêt à être poussé et s’il a été testé dans un environnement identique à celui de production. La meilleure méthode consiste donc à ajouter une étape de déploiement dans un environnement ressemblant à celui de production avant la release effective. Voici quelques-unes des bonnes pratiques :

- Déploiement en mode « canary release » : Il s’agit de pousser la mise à jour vers un petit groupe d’utilisateurs, de tester auprès d’eux et de déployer ensuite au plus grand nombre si tout s’est passé comme prévu (ou de revenir en arrière pour ensuite recommencer).

- Déploiement Blue-Green : Vous démarrez avec deux environnements de production identiques. L’un est live en production. L’autre est dormant. Chaque fois qu’une nouvelle version est déployée, les modifications sont poussées dans l’environnement dormant. Puis on alterne, l’environnement contenant la nouvelle version devient l’environnement live. En cas de problème, vous pouvez basculer immédiatement vers l’autre environnement (celui sans la nouvelle version). Si tout va bien, les environnements sont à parité.

- Tests A/B : Les tests A/B ressemblent aux déploiements Blue-Green mais ne doivent pas être confondus. Il s’agit là de tester des fonctionnalités dans l’application afin de mesurer leur facilité d’utilisation, par exemple. La variante la plus performante sera retenue. Il ne s’agit pas d’une méthodologie de distribution.

Utilisez des environnements de test à la demande

Exécuter des tests dans des conteneurs permet à l’équipe d’assurance qualité de réduire le nombre de variables dans l’environnement et de changements entre les environnements de développement et de production. Le principal avantage est que les environnements de test éphémères rendent votre cycle CI/CD plus agile. L’équipe d’assurance qualité n’a pas à extraire un build d’un serveur CI pour l’installer dans un environnement de test séparé ; elle peut au contraire exécuter les tests sur une image de conteneur. Il est bien plus simple de monter des conteneurs (qui sont sans contraintes d’installation ou de configuration séparées) et de les détruire une fois qu’ils ne sont plus utiles.

Par où commencer ?

Le principal objectif des bonnes pratiques DevOps et CI/CD réside dans l’automatisation du processus de build, test et distribution de logiciel. Pour commencer, il faut donc des outils DevOps pour simplifier l’automatisation et obtenir une meilleure visibilité sur la progression du logiciel. Par ailleurs, il faut un mécanisme de suivi des métriques de performance DevOps tout au long du cycle de déploiement de logiciel. Ce mécanisme doit également envoyer des alertes permettant une reprise rapide si jamais quelque chose devait mal se passer avec la nouvelle version ou le déploiement.

Quand l’intégration et le déploiement continus sont automatisés, l’approche de « shift-left testing », ou celle qui consiste à exécuter des tests plus tôt dans le processus, est possible. C’est un changement de perspective, de la détection vers la prévention des problèmes, ce qui suppose de tester toujours plus tôt, de manière à raccourcir les délais des cycles de test tout en préservant la qualité du code.

Résultat ? De meilleurs logiciels, livrés plus rapidement avec une boucle de rétroaction plus courte entre utilisateurs et développeurs. Outre les outils, le « shift-left testing » concerne la culture des équipes et les processus. Autrement dit, chacun est impliqué dans la livraison fiable de logiciels de haute qualité.

Auteur : Kristin Baskett, Senior Solutions Marketing Manager, CloudBees.