Samenvatting

  • 3 minuten

In deze module hebt u een implementatiepatroon gedefinieerd als een geautomatiseerde manier om nieuwe toepassingsfuncties soepel uit te rollen voor uw gebruikers. Een goed implementatiepatroon kan u helpen downtime te minimaliseren. Hiermee kunt u ook nieuwe functies geleidelijk implementeren voor uw gebruikers.

U kunt kiezen uit verschillende implementatiepatronen. Het implementatiepatroon dat u kiest, is afhankelijk van uw redenen voor de implementatie en uw resources. Heb je canary testers? Gebruikt u een donkere lancering en kiest u testers die niet weten dat ze testers zijn? Als u een vertrouwde set testers hebt die geleidelijk toeneemt van een kleine set naar een grotere set, kunt u een implementatie met progressieve blootstelling kiezen. Of als u wilt weten of een versie beter presteert dan een andere versie, kunt u A/B-tests kiezen.

Het Tailspin-team heeft ervoor gekozen om het blauwgroene implementatiepatroon te implementeren met behulp van implementatiesites in Azure App Service. Implementatiesleuven zijn live apps die hun eigen hostnamen hebben. Het team kan twee implementatieslots wisselen. Door te wisselen, kunnen ze wijzigingen in de productie onmiddellijk bevorderen. Hoewel het team niet klaar is om hun website openbaar te maken, hebben ze bewezen dat ze nieuwe functies voor hun gebruikers kunnen krijgen zonder uitvaltijd.

Als bonus hebt u in deze module ook geleerd hoe u een onbedoelde wijziging kunt doorsturen door een Git-doorvoer te herstellen en vervolgens de teruggedraaide wijziging via de pijplijn te pushen.

Hoe presteert het team?

In de Evalueer uw bestaande softwareontwikkelingsproces module, heeft Mara een oefening voor het toewijzen van waardestromen uitgevoerd. De oefening heeft het team geholpen bij het analyseren van hun huidige releasecyclusproces.

Zoals u weet, is de activiteitsverhoudingof efficiëntie procestijd gedeeld door totale doorlooptijd:

$${Activiteitsratio\ =\ }{\dfrac{Procestijd}{Totale\ doorlooptijd}}$$

Het Tailspin-webteam heeft deze metrische waarde in eerste instantie gebruikt om te bepalen dat ze 23 procent efficiënt waren.

Het team heeft eerst enkele inefficiënties verminderd bij het implementeren van continue integratie (CI). Door continue levering (CD) toe te passen, hebben ze nu nog meer inefficiënties verminderd.

In eerdere leertrajecten heeft het team het volgende verminderd:

  • De tijd die nodig is om broncodebeheer in te stellen voor nieuwe functies. De vereiste tijd ging van drie dagen naar nul dagen.

    Het team heeft deze verbetering bereikt door over te stappen van gecentraliseerd broncodebeheer naar Git, een vorm van gedistribueerd broncodebeheer. Door gedistribueerd broncodebeheer te gebruiken, hoeven ze niet te wachten tot bestanden zijn ontgrendeld.

  • De tijd die nodig is om code te leveren aan Amita, de tester. De vereiste tijd ging van twee dagen naar nul dagen.

    Het team heeft deze verbetering bereikt door het buildproces naar Azure Pipelines te verplaatsen. Met Azure Pipelines wordt Amita automatisch op de hoogte gesteld wanneer er een build beschikbaar is. Ontwikkelaars hoeven het spreadsheet van Amita niet meer bij te werken om haar hiervan op de hoogte te stellen.

  • De tijd die Amita nodig heeft om nieuwe functies te testen. De vereiste tijd ging van drie dagen naar één dag.

    Het team heeft deze verbetering bereikt door hun code te testen. Ze voeren eenheidstests uit telkens wanneer een wijziging door de build-pijplijn gaat, dus minder bugs en regressies bereiken Amita. De verminderde workload betekent dat Amita elke handmatige test sneller kan voltooien.

De releasepipeline die jij en het team in dit leertraject hebben gebouwd, is verminderd:

  • De tijd die nodig is om de build in de Test fase te brengen. De vereiste tijd ging van drie dagen naar één dag.

    Het team heeft dit bereikt met behulp van een geplande trigger om elke dag om 3:00 uur te implementeren in Test.

  • De tijd die het kost om de geteste build in Stagingte krijgen. De vereiste tijd ging van twee dagen naar nul dagen.

    Het team heeft deze verbetering bereikt door Selenium UI-tests, een vorm van functionele tests, toe te voegen aan de Test fase. Deze geautomatiseerde tests zijn veel sneller dan de handmatige versies.

  • De tijd die nodig is om de goedgekeurde build van Staging naar live te verplaatsen. De vereiste tijd ging van een dag naar minder dan een dag.

    Het team heeft deze verbetering bereikt door handmatige goedkeuringscontroles toe te voegen aan de pijplijn. Wanneer het management zich afmeldt, kan Tim de wijzigingen van faserings live vrijgeven.

Deze wijzigingen verminderen de totale doorlooptijd van 22 dagen tot 10 dagen. Wanneer we deze getallen invullen in de vergelijking:

$${Activiteitsratio\ =\ }{\dfrac{5\ dagen}{10\ dagen}}{ = 0,50}$$

Vermenigvuldig het resultaat met 100 procent en we krijgen een 50 procent reductie.

Hoewel er altijd ruimte is voor verbetering, is deze verandering een overwinning voor het team. Klanten krijgen niet alleen sneller waarde, het Tailspin-team besteedt nu minder tijd aan wachten en meer tijd om te doen waar ze het meest van genieten: functies leveren waarvan ze weten dat hun klanten zullen houden.

Meer informatie

Gebruik deze aanvullende bronnen voor meer informatie over App Service, implementatiesites en het terugdraaien van wijzigingen: