DevOps, de l’intégration continue au déploiement continu
Les premiers pas vers une industrialisation des développements consistent généralement en la mise en place d’une intégration continue.
Alors que celle-ci est souvent vue comme un aboutissement, elle n’est qu’une première étape pour parvenir à des réalisations efficaces et maîtrisées.
Article paru dans le magazine ICT Journal du mois de Juillet-Août 2014.
Intégration continue, un socle indispensable
Pièce maîtresse de l’usine de développement, le serveur d’intégration continue est essentiel à tout projet de développement logiciel. Que ce soit Jenkins, Bamboo ou autre, il assure la bonne compilation du code, le jeu des tests unitaires, le packaging, le déploiement et l’exécution des tests dans un environnement d’intégration. Il est en outre indépendant des configurations spécifiques aux postes de développeurs pour éviter tout contournement des règles de base de qualité (assurées par SonarQube, par exemple) et garantir la répétabilité des processus.
Le code packagé est archivé dans un référentiel central. Cette archive sera utilisée pour le déploiement sur l’ensemble des environnements, y compris la production.
L’intégration continue fiabilise les activités de développement. Une fois en place, elle autorise l'organisation projet à pousser l'industrialisation au-delà des frontières de l'équipe de développement.
Déploiement automatisé, une nécessité
Il devient alors possible d’automatiser progressivement les actions de déploiements auparavant réalisées manuellement par l’équipe d’exploitation (mise à jour de bases de données, déploiement dans un serveur d'applications, etc.).
En plus de supprimer des tâches fastidieuses, cette automatisation permet de fiabiliser le processus de déploiement tout en augmentant la fréquence des livraisons pour validation auprès des utilisateurs.
Ces déploiements automatisés peuvent aller de scripts de déploiement dans les cas les plus simples jusqu’à la recréation complète de l’environnement cible (via des outils comme Puppet, Chef ou Docker). Tout comme le code, ces scripts et paramétrages ont leur place dans un gestionnaire de sources.
Cette étape ne peut être franchie sans la collaboration entre les équipes de développement et d’exploitation.
A ce stade, le déploiement en intégration peut d’ores et déjà se faire automatiquement et fréquemment, s’il n’a pas d’impact au delà de l’équipe de développement. Les développeurs peuvent alors rapidement tester leur code dans un environnement proche de la cible.
En revanche, les déploiements sont déclenchés manuellement pour les environnements de qualification et de production, ce qui permet de rassurer l’ensemble des acteurs (équipe projet, clients et décideurs) tout en offrant un gain de temps non négligeable.
Tests d’acceptation automatisés, un idéal
Pour améliorer encore le time-to-market, il est nécessaire de réduire le temps dédié aux tests d’acceptation en environnement de qualification. Les testeurs, autrefois employés à les jouer de façon répétée, doivent désormais consacrer leur temps à la rédaction de tests automatisés. La qualité de ces tests ainsi que la couverture de l’application s’améliorent, ce qui assure la conformité aux attentes des utilisateurs.
L'exécution des tests est assujettie au déploiement automatisé de l’application, ce qui supprime encore des étapes manuelles et fluidifie le processus de livraison.
Déploiement continu en production, le graal ?
De nos jours, l’intégration continue est monnaie courante et son efficacité n’est plus à prouver. Elle constitue un prérequis pour quiconque souhaite moderniser ses pratiques de développements.
L’automatisation des déploiements en intégration est de plus en plus répandue, elle ajoute une visibilité aux développeurs quant à leurs réalisations.
L’automatisation des tests d’acceptation est moins fréquente. Elle correspond à une industrialisation poussée du processus de développement qui aboutit à une réduction du time-to-market.
Une fois la chaîne du développement jusqu’à la qualification maîtrisée, il ne reste plus qu'un pas à franchir pour parvenir au déploiement continu en production. Seule une poignée d’acteurs ont franchi le pas, de par la nature de leur activité (Google, Twitter, Amazon, etc.).
C'est ici que le changement est perçu comme le plus important, tant l'impact humain est grand. Des freins organisationnels notables subsistent (respect des normes, frilosité, communication lors des mises en production), et le bénéfice n’est pas évident pour tout le monde.