DevOpsMicrosoft release strategie voor Azure DevOps

Microsoft release strategie voor VSTS

Onlangs heeft Donovan Brown (Pincipal DevOps Manager) in een interview met Munil Shah (Director of Engineering) de release strategie voor Azure DevOps toegelicht. Oftewel, hoe Microsoft Azure DevOps (voorheen VSTS) naar productie brengt. In dit artikel een korte samenvatting. Onderaan de link naar het gehele interview.

Scale Units

Azure DevOps is een cloud product, dat draait op Azure in verschillende data centra. De keuze in welk data centrum een Azure DevOps domein wordt gehost, wordt bepaald door de geografische locatie. Uitgangspunt is dat de hosting zo dicht mogelijk plaatsvindt bij de locatie van de aanvrager. Voor de regio Western Europa is dit het data center in Nederland.
Een groep van Azure DevOps domeinen wordt een Scale Unit genoemd, hierin zitten dus meerdere domeinen en gebruikers. Wanneer het aantal gebruikers te groot wordt, dan wordt er een 2e scale unit opgeschakeld net zolang totdat er een derde Scale Unit moet komen et cetera.Scale Unit

Ringen

De release van een nieuwe versie wordt niet in één keer naar alle gebruikers gedaan, er is een onderverdeling gemaakt in een viertal groepen (ringen genoemd). In een ring zitten één of meerdere Scale Units. De volgende ringen onderkent:
- Ring 1: Het Microsoft VSTS team
- Ring 2: Een data center met een relatief klein aantal Scale Units (Brazilië in dit geval)
- Ring 3: Een data center in de VS met een groter aantal Scale Units
- Ring 4: Is de rest van de wereld (exclusief Microsoft Windows development team)
- Ring 4a: Het Microsoft Windows development team
De Microsoft sources zijn dermate groot en vereisen een aparte infrastructuur dat deze apart gereleased worden. Er is daarom voor gekozen deze apart te benoemen als Ring 4A. Release ringen

Release nieuwe software

Wanneer er een nieuwe versie gereleased wordt, dan wordt deze eerst uitgerold naar Ring 1, het Azure DevOps team. Nieuwe functionaliteit wordt dus als eerste binnen het team beschikbaar gesteld, waardoor feedback snel beschikbaar is. Impact op gebruikers wanneer een release niet goed is, is dan ook beperkt.

Na 24 uur (en in geval van positieve feedback) wordt de nieuwe versie naar Ring 2 gereleased. Ook hier wordt feedback verzameld. Wederom na 24 uur (en in geval van positieve feedback) wordt de nieuwe versie naar Ring 3 gereleased en als laatste wordt de nieuwe versie na wederom 24 uur naar Ring 4 en Ring 4A gereleased. De stappen worden geautomatiseerd uitgevoerd. De release van Ring 1 tot en met Ring 4 / 4A vindt plaats zonder tussenkomst van een medewerker.

Het releasen van een nieuwe versie voor een Hot fix release volgt hetzelfde proces. Enige verschil is dat een Sprint release enkele dagen duurt voordat het in alle ringen beschikbaar is, terwijl een Hot fix release binnen enkele uren in alle ringen beschikbaar is.

Software en Database wijzigingen

Een nieuwe versie kan zowel software wijzigingen als database wijzigingen bevatten. Bij de release van Azure DevOps is ervoor gekozen om eerst de software te releasen (waarbij de uitrol gefaseerd gaat naar de verschillende ringen). Deze release moet zowel met de oude als de nieuwe database schema’s werken. Als er een issue is na de uitrol van de software wordt de oude versie teruggezet. Als de uitrol van de software niet tot problemen leidt, wordt ook de database gereleased. Doen zich nu problemen voor, dan word er geen rollback gedaan maar wordt het probleem in productie opgelost.

Is deze werkwijze voor u ook interessant? Misschien wel, indien u interesse heeft neem dan contact met mij op dan kunnen we dit tijdens een persoonlijk gesprek bekijken.

In mijn volgende blog zal ik het testen en gebruik van feature flags uitlichten.

Marcel Groennou, DevOps Consultant

Klik hier om het gehele interview met Munil Shah terug te kijken.