Récapitulatif
Dans ce module, vous avez défini un modèle de déploiement pour automatiser le déploiement en douceur de nouvelles fonctionnalités d’application auprès des 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 progressivement de nouvelles fonctionnalités auprès des utilisateurs.
Vous avez le choix entre plusieurs modèles de déploiement. Le modèle de déploiement que vous choisissez dépend de la finalité du déploiement et de vos ressources. Disposez-vous de testeurs pour le contrôle de validité ? Allez-vous utiliser un « dark launch » (lancement dans l’ombre) et choisir des testeurs qui ne savent pas qu’ils sont testeurs ? Si vous disposez d’un ensemble de testeurs fiables qui augmente progressivement en nombre, vous pouvez choisir un déploiement avec exposition progressive. Ou, si vous souhaitez savoir si une version fonctionne mieux qu’une autre, vous pouvez choisir les tests 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 en production qui ont leurs propres noms d’hôtes. L’équipe peut échanger deux emplacements de déploiement. Grâce à cet échange, ils peuvent promouvoir instantanément des changements dans la phase de production. Bien que l’équipe ne soit pas prête à mettre en production son site web auprès du public, elle a prouvé qu’elle pouvait offrir de nouvelles fonctionnalités à ses utilisateurs sans provoquer 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 évaluer l’équipe ?
Dans le module Évaluer votre processus existant de développement de logiciels, Mara a effectué un exercice de cartographie de chaîne de valeur. L’exercice a aidé l’équipe à analyser son processus actuel de cycle de mise en production.
Rappelez-vous que le taux d’activité, ou l’efficacité, correspond au temps de traitement divisé par le délai total :
$${Taux\ d’activité\ =\ }{\dfrac{Temps de\ traitement}{Délai\ total}}$$
L’équipe web de Tailspin a utilisé initialement cette métrique pour déterminer que son taux d’efficacité était de 23 %.
L’équipe a d’abord réduit le gaspillage de productivité quand elle a implémenté l’intégration continue (CI). En appliquant la livraison continue (CD), elle a réduit encore un peu plus le gaspillage de productivité.
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 nécessaire est passé de trois jours à zéro jour.
L’équipe a obtenu cette amélioration en passant du contrôle de code source centralisé à Git, une forme de contrôle de code source distribué. Avec le contrôle de code source distribué, l’équipe n’a pas besoin d’attendre que les fichiers soient déverrouillés.
Le temps nécessaire à la fourniture du code à Amita, la testeuse. Le temps nécessaire est passé de deux jours à zéro jour.
L’équipe a obtenu cette amélioration en migrant son processus de génération vers Azure Pipelines. Azure Pipelines notifie automatiquement Amita quand une build est disponible. Les développeurs n’ont plus besoin de mettre à jour la feuille de calcul d’Amita pour lui notifier l’information.
Le temps nécessaire à Amita pour tester les nouvelles fonctionnalités. Le temps nécessaire est passé de trois jours à un jour.
L’équipe a obtenu cette amélioration en appliquant des tests unitaires au code. Elle effectue des tests unitaires chaque fois qu’un changement se produit dans le pipeline de build. Ainsi, moins de bogues et de régressions parviennent à Amita. La réduction de la charge de travail signifie qu’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 faire passer la build à la phase 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 faire passer la build testée à la phase Préproduction. Le temps nécessaire est passé de deux jours à zéro jour.
L’équipe est parvenu à cette amélioration en ajoutant des tests d’IU Selenium, une forme de test fonctionnel, à la phase 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 obtenu cette amélioration en ajoutant des vérifications d’approbation manuelles au pipeline. Quand la direction se déconnecte, Tim peut mettre en production les changements de la phase Préproduction.
Ces changements permettent de réduire le délai total de 22 à 10 jours. Lorsque nous substituons ces nombres dans l’équation :
$${Taux\ d’activité\ =\ }{\dfrac{5\ jours}{10\ jours}}{ = 0,5}$$
Multiplions le résultat par 100 %, et nous obtenons une réduction de 50 %.
Bien que des améliorations soient toujours possibles, ce changement est très positif pour l’équipe. Non seulement les clients obtiennent satisfaction plus rapidement, mais l’équipe de Tailspin consacre désormais moins de temps à attendre et plus de temps à faire ce qu’elle aime le plus : offrir à ses clients des fonctionnalités qui vont les combler.
En savoir plus
Utilisez ces ressources supplémentaires pour en savoir plus sur App Service, les emplacements de déploiement et la restauration des changements :