Le déploiement continu
Avant de commencer, clarifions ce qu'est l'intégration, la livraison et le déploiement continue.
Concrètement, on met en place un serveur d'intégration continue (Jenkins ou Bamboo) qui vérifie que le travail que l'équipe est en train de synchroniser est solide comme du béton.
Ce serveur s'assure que le code source synchronisé marche pas seulement sur le poste de développeur mais aussi sur les autres machines (serveurs de staging, QA, intégration, recette ou pré-production). Le serveur écoute les changements, commits, envoyés vers le contrôle de version, typiquement Git ou Subversion. Un build est lancé sur cette révision de code source et joue l'ensemble des tests. Si la compilation, les tests, ou tout autre chose échoue lors du build, alors le serveur en notifie le plus rapidement possible l'équipe ou le développeur afin de fixer le problème.
C'est la livraison de fonctionnalités et de correctifs au client dès qu'ils sont prêts. Cela implique un engagement dans l'assurance qualité constante et les tests constants ainsi qu'un niveau de couverture de test communiquant une confiance dans la livraison du logiciel.
Ainsi vous voulez passer d'une livraison hebdomadaire à une livraison à la fonctionnalité. Cela permet des upgrades plus rapides et d'une granularité plus fines et accélère le débogage et la détection de régression en changeant une chose à la fois.
Une livraison hebdomadaire n'est que semi-automatisée, alors que toutes les étapes d'une livraison à la fonctionnalité sont automatisées et pilotées par le serveur d'intégration continue rendant le processus de déploiement auto-documentant et répétable, libérant ainsi les sysadmins d'astreinte éventuelle et évitant des interventions humaines.
En automatisant le processus de livraison et déploiement, l'équipe peut livrer un travail en cours sur des serveurs de staging ou de QA donnant une visibilité sur l'état d'avancement. Cela bénéficie directement au client qui peut ainsi obtenir un feedback plus rapide et prendre de meilleures décisions pour la suite du projet. Les managers pourront voir le travail réalisé plus tôt et mesurer les progrès de l'équipe. Les développeurs ne seront plus stressés par les fenêtres de tir que sont les deadlines hebdomadaires (ou mensuelles) comme chaque fonctionnalité est maintenant livrée lorsqu'elle est prête. S'il faut 3 heures de plus pour terminer un développement alors il sera livré dans 3 heures.
Imaginez maintenant que vous ayez une fonctionnalité qui prenne 3 mois de développement. Comment utiliseriez-vous le déploiement continu afin de ne pas révéler une fonctionnalité à moitié implementée à chaque commit ou push? Le feature toggle permet de répondre à ce genre de problème.
Liens externes et références :
Cet article est révisé et publié continuellement.
L'intégration continue
C'est la pratique d'une équipe synchronisant leurs changements si fréquemment, plusieurs fois par jour, que c'en est presque continue.Concrètement, on met en place un serveur d'intégration continue (Jenkins ou Bamboo) qui vérifie que le travail que l'équipe est en train de synchroniser est solide comme du béton.
Ce serveur s'assure que le code source synchronisé marche pas seulement sur le poste de développeur mais aussi sur les autres machines (serveurs de staging, QA, intégration, recette ou pré-production). Le serveur écoute les changements, commits, envoyés vers le contrôle de version, typiquement Git ou Subversion. Un build est lancé sur cette révision de code source et joue l'ensemble des tests. Si la compilation, les tests, ou tout autre chose échoue lors du build, alors le serveur en notifie le plus rapidement possible l'équipe ou le développeur afin de fixer le problème.
La livraison continue
Si les tests sont lancés constamment et que vous y accordez une confiance garantissant un niveau de qualité, alors il est possible de livrer le logiciel au moment où vous le souhaitez ou bien lorsque votre client le souhaite. Votre logiciel est ainsi prêt-à-livrer.Le déploiement continu
Le déploiement continu est l'étape d'après. Dès que le logiciel est prêt-à-livrer, il est automatiquement déployé en production.C'est la livraison de fonctionnalités et de correctifs au client dès qu'ils sont prêts. Cela implique un engagement dans l'assurance qualité constante et les tests constants ainsi qu'un niveau de couverture de test communiquant une confiance dans la livraison du logiciel.
Ainsi vous voulez passer d'une livraison hebdomadaire à une livraison à la fonctionnalité. Cela permet des upgrades plus rapides et d'une granularité plus fines et accélère le débogage et la détection de régression en changeant une chose à la fois.
Une livraison hebdomadaire n'est que semi-automatisée, alors que toutes les étapes d'une livraison à la fonctionnalité sont automatisées et pilotées par le serveur d'intégration continue rendant le processus de déploiement auto-documentant et répétable, libérant ainsi les sysadmins d'astreinte éventuelle et évitant des interventions humaines.
En automatisant le processus de livraison et déploiement, l'équipe peut livrer un travail en cours sur des serveurs de staging ou de QA donnant une visibilité sur l'état d'avancement. Cela bénéficie directement au client qui peut ainsi obtenir un feedback plus rapide et prendre de meilleures décisions pour la suite du projet. Les managers pourront voir le travail réalisé plus tôt et mesurer les progrès de l'équipe. Les développeurs ne seront plus stressés par les fenêtres de tir que sont les deadlines hebdomadaires (ou mensuelles) comme chaque fonctionnalité est maintenant livrée lorsqu'elle est prête. S'il faut 3 heures de plus pour terminer un développement alors il sera livré dans 3 heures.
Imaginez maintenant que vous ayez une fonctionnalité qui prenne 3 mois de développement. Comment utiliseriez-vous le déploiement continu afin de ne pas révéler une fonctionnalité à moitié implementée à chaque commit ou push? Le feature toggle permet de répondre à ce genre de problème.
Liens externes et références :
http://martinfowler.com/bliki/FeatureToggle.html
http://blogs.atlassian.com/2014/04/practical-continuous-deployment/
https://puppetlabs.com/blog/continuous-delivery-vs-continuous-deployment-whats-diff
http://blogs.atlassian.com/2014/04/practical-continuous-deployment/
https://puppetlabs.com/blog/continuous-delivery-vs-continuous-deployment-whats-diff
Cet article est révisé et publié continuellement.
Commentaires
Enregistrer un commentaire