A déploiement continu automatisé, code bien géré
Le déploiement continu implique de sauter l'étape de contrôle des opérations. L’automatisation doit ainsi garantir un déploiement propre, avant que des erreurs soient commises en production.
DevOps est toujours associé au mot « continu ». A tel point qu’il devient synonyme de livraison ou de déploiement rapide du code au sein d’environnements de production.
Le déploiement continu, lorsque les modifications de code passent directement à la production, est un objectif prioritaire pour nombre d’entreprises. Toutefois, peu d'entre elles y parviennent réellement. Cela est en effet difficile, les barrières à l’adoption sont multiples.
La phase de déploiement intervient en bout de chaîne, à la l’extrémité du pipeline. Le déploiement continu (parce qu’il est justement continu) exige donc de choisir des outils au début du cycle - comme le contrôle de version - jusqu'à sa fin - l’approbation du déploiement - , et comprend tous les services de build et de test entre ces deux phases.
Le déploiement continu doit ainsi se concrétiser avec trois catégories distinctes d’outils :
- Le contrôle de version ;
- l'automatisation des phases de build avec des tests ; et
- le déploiement avec tests.
Chacun des outils peut appartenir à une ou plusieurs de ces catégories, mais pour pratiquer le déploiement continu, une entreprise doit disposer d’au moins un outil dans chaque catégorie.
Suivi des versions de code
En matière de déploiement continu, le contrôle de version n'est pas seulement une exigence ; il s’agit d’une nécessité pour presque tous les projets. Les outils de contrôle de versions permettent aux développeurs de vérifier ou de valider les modifications de code. Ces changements sont ensuite suivis dans le temps – cela empêche par exemple d’être confronté à des noms de fichiers, comme feature.bak ou feature2.bak2.bak2. L'historique complet d’une version est joint à chaque fichier, ce qui permet à un développeur de visualiser ou de revenir à un état spécifique du code à un instant T.
Le contrôle de version permet aussi de créer des copies d'une base de code entière et de travailler à partir de cette base. En créant cette branche, un développeur peut changer autant de base de code qu'il le souhaite sans se soucier des autres branches. Une fois les travaux terminés, il peut fusionner ces changements avec la source originale, en recréant une seule branche.
Il existe différents types d'outils de contrôle de version. Git, et GitHub donc, sont parmi les plus populaires. Git est un système de contrôle de version avec lequel les développeurs créent un référentiel, appelé repo, sur leur ordinateur, en local, pour vérifier leur code. Git offre toutes les fonctionnalités typiques des outils de contrôle de version : vérification de code, création de branches et fusion de code. Git s’appuie sur un système distribué parce que les repos Git existent uniquement sur l'ordinateur local d'un développeur. Cependant, cela pose un problème de collaboration. Synchroniser tous les dépôts Git est difficile, c'est pourquoi GitHub relie ces dépôts Git ensemble.
D’autres services sont également proposés par GitHub, comme les demandes de contribution de code, le suivi des bogues et des fonctionnalités et la documentation. GitHub a popularisé Git et a facilité le démarrage d'un nouveau projet avec les dépôts Git.
Automatiser les phases de build
Une fois le code vérifié dans le contrôle de version, la phase de build démarre. Cela correspond à toutes les actions nécessaires pour assembler le code et les artefacts dans un logiciel consommable par l'utilisateur final. Cela peut consister à compiler du code, à packager et à fusionner plusieurs bibliothèques.
Les outils d'automatisation de build définissent les différentes étapes de création d'une build. Chaque outil effectue cette tâche un peu différemment.
Tout outil digne de confiance inclut une fonction de test. Les méthodes de test, comme les tests unitaires, sont généralement appliquées à cette étape. Les tests unitaires garantissent que les changements récents n'ont pas introduit de bugs. Si les tests sont développés correctement, ils exécutent le code dans un grand nombre de contextes différents et tiennent compte de la façon dont le code pourrait être exécuté dans chacun d’entre eux. Ce test automatisé est important dans le déploiement continu, où les modifications du code sont immédiatement mises en production sans intervention humaine. Dans le cas de la livraison continue, le code s'arrête aux équipes opérationnelles avant la release.
Le bon outil d'automatisation de build dépend en fait du type de projet. MSBuild est bien connu pour les projets exploitant les technologies Microsoft. Team Foundation Server et Visual Studio Team Services (VSTS) offrent également des fonctionnalités d'intégration continue. Pour les projets open source, Jenkins, TravisCI et TeamCity ont davantage la cote.
Déployer un code qui résiste
Le déploiement est la phase finale et la plus critique dans les pipelines de déploiement continu. À ce stade, on prend le résultat des phases de build et on l’envoie aux serveurs de production ou on met à jour son environnement de production dans le cloud.
Les outils de déploiement continu, tels que Jenkins, VSTS, Octopus Deploy et AWS CodeDeploy, déploient le code en production via des scripts et effectuent immédiatement des tests d'intégration et d'approbation. Il s'agit là d'un moment critique. Par conséquent, tous les outils de déploiement de code sont intégrés aux procédures de test. Les outils de déploiement permettent à l'ingénieur dédié aux phases de build/release ou au développeur de déployer personnellement le code en production et d'exécuter immédiatement une série de tests pour s'assurer qu'il fonctionne. Ces tests confirment que le code est fonctionnel, ce qui est parfois difficile à dire.
Le déploiement et la configuration sont gérés par des outils d'automatisation et de gestion de configuration, comme Puppet et Ansible. Les tests d'intégration et d'approbation s'exécutent lors du déploiement. Les outils de monitoring, tels que ceux d'AppDynamics et de Splunk, analysent et signalent tous changements de performances de l'application et / ou de l'infrastructure provoqués par cet ajout de code. Ils fonctionnent de pair avec des outils de gestion de réponse aux incidents, tels que PagerDuty. Dans le déploiement continu, le monitoring et la réponse aux incidents doivent être effectués en quasi temps réel afin de raccourcir les temps de récupération.
Si quelque chose tourne mal, l’outil de déploiement continu doit disposer d’une fonction de rollback (retour en arrière) pour annuler tous les changements et revenir à un état antérieur.
Sans risque, pas de récompense ?
Le déploiement continu est le moyen le plus rapide de livrer un logiciel en production, mais c'est aussi, selon certains experts, le plus risqué. Toutefois, les outils dédiés éliminent une grande partie de ce risque grâce à l'intégration de tests à toutes les étapes du processus. Certains envoient des avis d'approbation automatisés. Mais, ces notifications s'éloignent quelque peu d'un véritable pipeline de déploiement continu.
Certaines entreprises préfèrent quant à elles utiliser un ensemble d'outils pour gérer les différents aspects du pipeline, tandis que d'autres utilisent un seul outil pour tout le pipeline. Si vous devez faire un choix, il convient de tenir compte du pipeline dans sa totalité, de la culture de l’entreprise et de la tolérance à l'égard de l'échec.