Livrer rapidement

Impossible de parler du DevOps sans parler de l’intégration et de la distribution continues. Dans cette vidéo, nous allons vous présenter leurs 5 principaux avantages. Avec l’ancienne méthode de distribution, l’application n’est presque jamais exécutée pendant son développement, du moins, pas dans son intégralité. On développe et on déploie, et on la soumet à une phase de test à la fin. Vers la fin du projet, on reçoit donc des tonnes de rapports de bugs. Avec la distribution continue, l’application est développée automatiquement à chaque commit du code. Les tests unitaires sont exécutés, et l’application est déployée dans un environnement de type production. Des tests d’acceptation automatisés sont également effectués, et les changements sont acceptés ou rejetés après leur soumission. Le code est toujours fonctionnel à chaque distribution continue. Passons aux définitions. L’intégration continue, c’est effectuer automatiquement les builds et les tests unitaires de l’application complète, fréquemment. Idéalement, à chaque soumission du code source. La distribution continue, c’est déployer chaque changement dans un environnement de type production, et effectuer l’intégration et les tests d’acceptation de manière automatisée. Le déploiement continu est le prolongement de cela, avec des tests automatisés complets pour chaque changement, et enfin le déploiement automatique en production. Les grandes plateformes comme Facebook, Etsy et Wealthfront s’appuient sur le déploiement continu. Un des principaux attraits de ces techniques est la réduction considérable des délais de mise sur le marché. Le rapport State of DevOps de 2016 montre que les organisations IT performantes peuvent déployer à la demande, par opposition à plusieurs jours, semaines ou mois chez les autres. Les organisations performantes sont capables de passe rapidement de Concept à Cash. Elles peuvent ainsi tester et valider leurs idées rapidement. Aujourd’hui, certaines peuvent même déployer une application des dizaines ou des centaines de fois par jour. Vous vous dites peut-être que cette rapidité et ces changements successifs nuisent à la qualité, mais c’est tout le contraire. Le rapport State of DevOps a aussi montré que ces organisations connaissent trois fois moins d’échecs que les autres quand elles déploient des changements. La qualité augmente, car au lieu de faire les vérifications à la fin du cycle de développement, on fait les tests plus tôt dans le pipeline de distribution. Au lieu d’une date de lancement globale incluant des centaines de changements, ces derniers sont évalués et déployés un à un. Chaque commit est testé, et on s’assure que le logiciel soit fonctionnel. Vous savez, comme on l’apprend en Lean, il est très risqué d’avoir un grand nombre de tâches en cours simultanément. En intégration continue, on recommande aux développeurs de travailler à partir du Master, ou du Trunk, une pratique clé mais controversée. Le rapport State of DevOps montre en effet que les branches ou les intersections éphémères intégrées au Trunk en l’espace d’une journée et que le fait de se limiter à trois branches actives contribuent à la performance. En bref, on limite le nombre de changements intégrés qui sont l’équivalent logiciel du travail en cours. Personnellement, j’ai eu ce déclic en lisant le livre de Jez Humble sur la livraison continue. Dedans, il propose une taille de lot de 1. On y trouve aussi cette phrase intéressante : « L’important n’est pas le maximum que vous pouvez livrer, mais le minimum ». - Le rapport State of DevOps indique aussi que les organisations performantes peuvent déployer les changements en production en moins d’une heure. Chez les moins performants, il faut compter entre 1 et 6 mois. C’est un avantage compétitif de taille. Combien de temps mettez-vous pour vous sortir d’une panne ? L’avantage des environnements de distribution continue, c’est qu’on a deux vecteurs qui accélèrent le délai moyen de reprise. Un, lorsque vous trouvez une mesure corrective pour faire face à un état d’échec, vous pouvez la traiter et la déployer rapidement, avec votre processus habituel pour le déploiement des changements. Deux, et c’est moins évident, vous pouvez utiliser la distribution continue pour trouver la cause de l’échec. Au travail, nous avions constaté une augmentation des connexions à la base de données sur plusieurs jours. Elles ont continué d’augmenter jusqu’à la limite, et tout a planté. En superposant le graphique des connexions sur celui des déploiements à la même période, j’ai pu trouver facilement le commit à l’origine de l’erreur. Dans mon ancienne entreprise, ce processus prenait des semaines, car les changements étaient déployés chaque trimestre, par centaines simultanément. Pour moi, cela prouve que la distribution continue réduit le MTTR et influe considérablement sur les opérations. Dans les sections suivantes, nous allons parler de l’intégration continue et des pipelines et pratiques de distribution continue qu’il convient d’appliquer.