Dans cette partie, nous allons voir comment livrer votre code en continu pour le mettre en production rapidement, et de manière fiable.
La livraison continue est la suite logique de l'intégration continue. Dans l'intégration continue, nous cherchons à ce que le code compile bien, mais aussi qu'il soit fonctionnel en production et de qualité, en lançant le plus régulièrement possible les tests unitaires. Mais il existe d'autres types de tests, tout aussi importants, pour garantir la qualité du code. Ces tests ne peuvent cependant pas être lancés sans avoir un environnement déployé.
La livraison continue est une discipline où l'application est construite de manière à pouvoir être mise en production à n'importe quel moment.
Pour atteindre la mise en oeuvre de la livraison continue sur une application, il est nécessaire de mettre en place plusieurs étapes supplémentaires au sein de notre pipeline.
Dans la suite de ce chapitre, nous allons détailler chacune de ces étapes.
Étape 1 : Codifiez votre infrastructure avec l'Infrastructure-as-Code
Les avantages sont nombreux :
possibilité de créer des environnements à la demande ;
création d'environnement en quelques minutes, contre plusieurs semaines dans une entreprise classique ;
pilotage de l'infrastructure grâce au pipeline de livraison continue ;
connaissance des logiciels installés sur la plateforme, grâce à l'outillage ;
montée de version des environnements automatisés.
Nous découvrirons comment déployer des infrastructures rapidement avec l'Infrastructure-as-Code, dans le chapitre 2.
Étape 2 : Déployez votre application
L'étape la plus importante de la livraison continue est le déploiement du package que nous avons précédemment créé lors de l'intégration continue. Les avantages d'utiliser un outil pour automatiser le déploiement de l'application sont nombreux :
cela permet à l'équipe de se concentrer sur le développement, là où elle a sa valeur à ajouter ;
n'importe qui dans l'équipe peut déployer des logiciels ;
les déploiements deviennent beaucoup moins sujets aux erreurs et beaucoup plus reproductibles ;
déployer sur un nouvel environnement est facile ;
les déploiements peuvent être très fréquents.
Nous mettrons en place le déploiement automatique du code dans le chapitre 3.
Étape 3 : Testez votre application
C'est dans cette étape que nous allons ajouter d'autres types de tests, plus pertinents et plus fonctionnels, afin de garantir que l'application fonctionne comme nous l'avons estimé.
L'avantage de tester à ce stade du pipeline est que l'application tourne sur un environnement de test, presque identique à celui de la production. Son comportement sera donc le plus fidèle possible à celui qu'elle aura en production.
Ces tests peuvent être de différents types :
Test d'acceptance
Les tests d'acceptance sont des tests formels exécutés pour vérifier si un système satisfait à ses exigences opérationnelles. Ils exigent que l'application entière soit opérationnelle et se concentrent sur la réplication des comportements des utilisateurs. Mais ils peuvent aussi aller plus loin en mesurant la performance du système, et rejeter les changements si certains objectifs ne sont pas atteints.
Ces tests peuvent être automatisés, mais aussi manuels, avec une équipe de test dédiée qui regardera si le logiciel correspond au besoin.
Test de performance
Les tests de performance vérifient le comportement du système lorsqu'il est soumis à une charge importante. Ces tests ne sont pas fonctionnels et peuvent prendre différentes formes pour comprendre la fiabilité, la stabilité et la disponibilité de la plateforme. Par exemple, il peut s'agir d'observer les temps de réponse lors de l'exécution d'un grand nombre de requêtes, ou de voir comment le système se comporte avec une quantité importante de données.
Les tests de performance sont par nature assez coûteux à mettre en œuvre et à exécuter, mais ils peuvent vous aider à comprendre si de nouveaux changements vont dégrader votre système.
Smoke test
Les smoke tests sont des tests de base qui vérifient les fonctionnalités de base de l'application. Ils sont conçus pour être rapides à exécuter, et leur but est de vous donner l'assurance que les principales caractéristiques de votre système fonctionnent comme prévu. Ils peuvent être utiles juste après une nouvelle build, pour décider si vous pouvez ou non exécuter des tests plus coûteux, ou juste après un déploiement pour s'assurer que l'application fonctionne correctement dans le nouvel environnement déployé.
Par exemple, les smoke tests peuvent s'assurer que la base de données répond et est correctement configurée, mais aussi que les différents composants sont présents et envoient des données correctes, comme des API qui devraient répondre un code HTTP 200, ou une page web qui devrait s'afficher.
Nous mettrons en place le lancement automatique des tests dans le chapitre 3.
Étape 4 : Supervisez le comportement de votre application
Le monitoring, ou supervision, intervient une fois que notre application est déployée sur un environnement, que ce soit un environnement de staging, de test, de démonstration ou bien l'environnement de production lui-même.
Le principe est de récupérer certaines métriques qui ont du sens pour ceux qui interviennent sur l'application. Cela peut être par exemple le nombre de connexions HTTP, le nombre de requêtes à la base de données, le temps de réponse de certaines pages ; mais aussi des métriques plus orientées métier, comme le chiffre d'affaires généré, ou le nombre de personnes inscrites sur l'application.
Les métriques peuvent être aussi sur la partie livraison en elle-même, ou sur le processus de développement. Par exemple, l'équipe peut mesurer le nombre de déploiements qu'elle effectue par jour, ou encore deux autres indicateurs qui sont importants afin de voir la performance de l'équipe sur la correction d'erreurs qui peuvent survenir en production :
Le Mean-Time-Between-Failure
Le Mean-Time-Between-Failure (ou MTBF) est le temps moyen qui sépare deux erreurs en production. Plus ce temps est élevé, plus le système est stable et fiable, notamment du fait de la qualité des tests qui sont joués lors de la livraison continue.
Le Mean-Time-To-Recover
Le Mean-Time-To-Recover (ou MTTR) est le temps moyen de correction entre deux erreurs de production. Plus ce temps est faible, plus l'équipe est apte à détecter des erreurs et à les corriger rapidement.
Nous verrons comment superviser l'application dans le chapitre 4.
Étape 5 : Mettez en place des notifications d'alertes
La première version d'une nouvelle fonctionnalité ou d'un nouveau produit ne couvre souvent pas entièrement les besoins des clients. Même lorsque l'équipe passe des semaines ou des mois à construire quelque chose, le produit final est souvent voué à manquer des fonctionnalités importantes. C'est le principe du Minimum Viable Product (MVP) en Agile.
Il arrive donc très souvent de livrer des logiciels incomplets ou buggés, si l'équipe veut aller assez vite. Au lieu de vouloir éviter cela, il est nécessaire d'adopter l'idée de livrer des petites pièces de valeur.
En livrant plus vite, nous pouvons réparer les bugs tant que les livraisons restent petites, et que nous savons ce qui a été modifié dans l'application. Quand les développements grossissent, ils deviennent plus difficiles à gérer et à remanier. Un feedback rapide, grâce aux tests en production et au monitoring, permet d'intervenir et de corriger le problème dès que possible. Il nous permet d'apprendre des clients, et des erreurs, au bon moment.
Une fois le déploiement fini et les différents tests effectués, il est nécessaire d'avoir un feedback rapide de l'utilisation du logiciel. En effet, si le déploiement de la nouvelle version du logiciel apporte des bugs malgré les différents tests effectués, il faut alors les détecter le plus rapidement possible, afin de pouvoir proposer une nouvelle correction au logiciel.
Nous verrons comment mettre en place des outils de notification rapide en cas de problème, dans le chapitre 4.
En résumé
Ça y est, ce chapitre de présentation du déploiement continue est terminé !
Pour résumer, voici les grandes étapes de la livraison continue :
La codification de l'infrastructure avec l'Infrastructure-as-Code, et notamment en construisant des images avec Docker.
Le déploiement des images de votre application.
Le test de votre application en environnement de test.
La supervision de l'application, grâce à plusieurs métriques suivies automatiquement.
La mise en place de notifications d'alerte automatiques grâce à Twitter, Slack ou Trello.
Vous avez maintenant une meilleure vue d'ensemble des différentes étapes qui la composent.
Dans la suite de cette partie, vous allez mettre en place ces étapes grâce à GitLab et d'autres outils !
