Résumé
Dans ce module, vous avez défini un modèle de déploiement comme un moyen automatisé de déployer en douceur de nouvelles fonctionnalités d’application pour vos utilisateurs. Un bon modèle de déploiement peut vous aider à réduire les temps d’arrêt. Il peut également vous permettre de déployer de nouvelles fonctionnalités progressivement pour vos utilisateurs.
Vous pouvez choisir parmi plusieurs modèles de déploiement. Le modèle de déploiement que vous choisissez dépend de vos raisons pour le déploiement et vos ressources. Disposez-vous de testeurs pour le contrôle de validité ? Allez-vous utiliser un lancement sombre et choisir des testeurs qui ne savent pas qu’ils sont testeurs ? Si vous avez un ensemble approuvé de testeurs qui augmente progressivement d’un petit ensemble à un ensemble plus grand, vous pouvez choisir un déploiement progressif d’exposition. Ou, si vous souhaitez savoir si une version fonctionne mieux qu’une autre version, vous pouvez choisir un test A/B.
L’équipe Tailspin a choisi d’implémenter le modèle de déploiement bleu-vert à l’aide d’emplacements de déploiement dans Azure App Service. Les emplacements de déploiement sont des applications actives qui ont leur propre nom d’hôte. L’équipe peut échanger deux emplacements de déploiement. En échangeant, ils peuvent promouvoir instantanément les modifications apportées à la production. Bien que l’équipe ne soit pas prête à publier son site web auprès du public, elle a prouvé qu’elle pouvait fournir de nouvelles fonctionnalités à ses utilisateurs sans entraîner de temps d’arrêt.
En prime, dans ce module, vous avez également appris à effectuer la restauration par progression d’un changement involontaire en restaurant un commit Git et en poussant le changement annulé via le pipeline.
Comment l'équipe s'en sort-elle ?
Dans le module Évaluer votre processus de développement logiciel existant , Mara a effectué un exercice de mappage de flux de valeurs. L’exercice a aidé l’équipe à analyser son processus de cycle de publication actuel.
Rappelez-vous que le ratio d’activité ou l’efficacité est divisé par temps de traitement total :
$${Taux\ activité\ =\ }{\dfrac{Temps\ traitement}{Total\ temps\ lead}}$$
L’équipe web Tailspin a initialement utilisé cette métrique pour déterminer qu’elle était efficace de 23 %.
L’équipe a d’abord réduit certaines inefficacités lorsqu’elle a implémenté l’intégration continue (CI). En appliquant une livraison continue (CD), ils ont maintenant réduit encore davantage les inefficacités.
Dans les parcours d’apprentissage précédents, l’équipe a réduit :
Le temps nécessaire à la configuration du contrôle de code source pour les nouvelles fonctionnalités. Le temps requis est passé de trois jours à zéro jours.
L’équipe a réalisé cette amélioration en passant du contrôle de code source centralisé à Git, une forme de contrôle de code source distribué. En utilisant le contrôle de code source distribué, ils n’ont pas besoin d’attendre que les fichiers soient déverrouillés.
Le temps nécessaire à la livraison du code à Amita, le testeur. Le temps nécessaire est passé de deux jours à zéro jours.
L’équipe a réalisé cette amélioration en déplaçant son processus de génération vers Azure Pipelines. Azure Pipelines avertit automatiquement Amita lorsqu’une build est disponible. Les développeurs n’ont plus besoin de mettre à jour la feuille de calcul d’Amita pour la notifier.
Le temps nécessaire à Amita pour tester de nouvelles fonctionnalités. Le temps nécessaire est passé de trois jours à un jour.
L’équipe a réalisé cette amélioration en testant son code en unité. Ils exécutent des tests unitaires chaque fois qu’une modification passe par le pipeline de build, donc moins de bogues et de régressions atteignent Amita. La charge de travail réduite signifie que Amita peut effectuer chaque test manuel plus rapidement.
Le pipeline de mise en production que vous et l’équipe avez créé dans ce parcours d’apprentissage a permis de réduire :
Le temps nécessaire pour amener la version à la phase de test. Le temps nécessaire est passé de trois jours à un jour.
L’équipe a obtenu ce résultat en utilisant un déclencheur planifié pour effectuer un déploiement sur Test tous les jours à 3h00 du matin.
Le temps nécessaire pour obtenir la version testée en préproduction. Le temps nécessaire est passé de deux jours à zéro jours.
L’équipe a réalisé cette amélioration en ajoutant des tests de l’interface utilisateur Selenium, une forme de test fonctionnel, à la phase de test . Ces tests automatisés sont beaucoup plus rapides que les versions manuelles.
Le temps nécessaire pour passer la build approuvée de la phase Préproduction à la production. Le temps nécessaire est passé d’un jour à moins d’un jour.
L'équipe a réalisé cette amélioration en intégrant des vérifications d'approbation manuelles dans le processus de pipeline. Quand la direction valide, Tim peut mettre en production les changements de la phase Préproduction.
Ces modifications réduisent le délai total de 22 jours à 10 jours. Lorsque nous substituons ces nombres à l’équation :
$${Taux\ activité\ =\ }{\dfrac{5\ jours}{10\ jours}}{ = 0.50}$$
Multipliez le résultat par 100 % et nous obtenons une réduction de 50 %.
Bien qu’il y ait toujours de la place pour l’amélioration, ce changement est une victoire pour l’équipe. Non seulement les clients obtiennent de la valeur plus rapidement, l’équipe Tailspin passe maintenant moins de temps à attendre et plus de temps à faire ce qu’ils apprécient le plus : fournir des fonctionnalités qu’ils savent que leurs clients aimeront.
Pour en savoir plus
Utilisez ces ressources supplémentaires pour en savoir plus sur App Service, les emplacements de déploiement et la restauration des modifications :