Så levererar Microsoft programvara med DevOps

Microsoft har årtionden av erfarenhet av att leverera mycket skalbara tjänster till produktionsmiljöer. I takt med att Microsofts tjänster och miljöer har utökats har deras leveransmetoder också utvecklats med tiden. Många Microsoft-kunder har också antagit och drar nytta av dessa effektiva leveransmetoder. Följande grundläggande DevOps-principer och -processer kan gälla för alla moderna programvaruleveransinsatser.

För att implementera DevOps-leveransprocesser antog Microsoft följande initiativ:

• Inrikta organisationens tankesätt och arbetsrytm på leverans.
• Skapa autonoma, ansvariga team som äger, testar och levererar funktioner.
• Flytta tester och övervakning närmare produktion.

Fokus på leverans

Snabbare leverans är en uppenbar fördel som organisationer och team enkelt kan mäta och uppskatta. Den typiska DevOps-kadensen omfattar korta sprintcykler med regelbundna distributioner till produktion.

Vissa lag var rädda för bristande produktstabilitet med korta sprintar och hade kompenserat med stabiliseringsperioder i slutet av sina sprintcykler. Ingenjörer ville skicka så många funktioner som möjligt under sprinten, så de ådrog sig testskulder som de var tvungna att betala ner under stabiliseringen. Team som hanterade sin skuld under sprinten var sedan tvungna att stödja de team som byggde upp skulder. De extra kostnaderna utvecklade sig genom leveranskedjorna och in i produktionen.

Att ta bort stabiliseringsperioden förbättrade snabbt hur teamen hanterade sin skuld. I stället för att skjuta upp nyckelunderhållsarbetet till stabiliseringsperioden var team som byggde upp skulder tvungna att spendera nästa sprint för att komma ikapp sina skuldmål. Teamen lärde sig snabbt att hantera sina testskulder under sprintarna. Funktionerna levereras när de är beprövade och värda kostnaden för distributionen.

Automatisera pipelines helt

Mycket av det som förbättringsteamen kan uppnå omedelbart är att helt automatisera pipelines från kodförråd till produktion. Automation inkluderar versionspipelines med kontinuerlig integrering (CI), automatiserad testning och kontinuerlig leverans (CD).

Team kan undvika att distribuera eftersom det är svårt, men ju mindre ofta de distribuerar, desto svårare är det. Ju mer tid mellan distributioner, desto fler problem hopar sig. Om koden inte är färsk finns det distributionsskulder.

Det är enklare att arbeta i mindre delar genom att distribuera ofta. Den här idén kan verka uppenbar i efterhand, men på den tiden kan den verka kontraintuitiv. Frekventa distributioner motiverar också teamen att prioritera skapandet av effektivare och mer tillförlitliga distributionsverktyg och pipelines.

Använda interna verktyg

Microsoft använder det versionshanteringssystem som de skapar och skickar det till kunderna. En enda investering förbättrar både teamets produktivitet och Microsofts produkter. Att använda ett sekundärt system skulle suga av utveckling och leveranshastighet.

Teamets autonomi och ansvar

Inga specifika KPI:er (Key Progress Indicators) mäter teamets produktivitet eller prestanda, eller om en funktion är på rätt spår. Team måste kunna hantera sina egna planer och kvarvarande uppgifter, samtidigt som de hittar ett sätt att anpassa sig till organisationens mål.

Det är viktigt att kommunicera direkt med team för att spåra förloppet. Verktyg bör underlätta kommunikationen, men konversation är det mest transparenta sättet att kommunicera.

Prioritera funktioner

Ett viktigt mål är att fokusera på att leverera funktioner. Scheman kan utvärdera hur mycket team och individer rimligen kan slutföra under en viss tidsperiod, men vissa funktioner levereras tidigare och vissa levereras senare. Teams kan prioritera arbetet så att de viktigaste funktionerna tar sig till produktion.

Använda mikrotjänster

Mikrotjänster erbjuder olika tekniska fördelar som förbättrar och förenklar leveransen. Mikrotjänster ger också naturliga gränser för teamägarskap. När ett team har autonomi över investeringar i en mikrotjänst kan de prioritera hur man implementerar funktioner och hanterar skulder. Teams kan fokusera på planer för faktorer som versionshantering, oberoende av de övergripande tjänster som är beroende av mikrotjänsten.

Arbeta i huvudområdet

Ingenjörer brukade arbeta i separata grenar. Sammanslagningsskulden för varje gren växte tills ingenjören försökte integrera sin gren i huvudgrenen. Ju fler team och ingenjörer det fanns, desto större blev integrationen.

För att integreringen ska gå snabbare, mer kontinuerligt och i mindre segment arbetar nu tekniker i huvudgrenen. En stor anledning till att flytta till Git var de enkla git-erbjudandena för förgrening. Fördelen med intern teknik var att eliminera den djupa grenhierarkin och dess slöseri. All tid som tidigare användes för att integrera läggs nu på leverans.

Använda funktionsflaggor

Vissa funktioner är inte helt färdiga för en sprintdistribution, men kan fortfarande dra nytta av testning i produktion. Teams kan slå samman och distribuera den här koden med funktionsflaggor för att aktivera funktionen för specifika användare, till exempel utvecklingsteamet eller ett litet segment av tidiga användare. Funktionsflaggor styr exponeringen utan att riskera problem med den övergripande användarbasen och kan hjälpa teamen att avgöra om och hur funktionen ska slutföras.

Testning i produktion

Genom att flytta rätten att testa i produktion ser du till att förproduktionstesterna är giltiga och att ständigt föränderliga produktionsmiljöer är redo att hantera distributioner.

Instrumenttester och mått

Oavsett var en app distribueras är det viktigt att instrumentera allt. Instrumentation hjälper inte bara till att identifiera och åtgärda problem, utan kan ge ovärderlig forskning om användning och vad som ska läggas till härnäst.

Testa återhämtningsmönster

En risk för komplexa distributioner är sammanhängande fel, där ett komponentfel gör att beroende komponenter misslyckas och så vidare tills hela systemet bryts ned. Det är viktigt att förstå var enskilda felpunkter (SPOF:er) finns och hur de minimeras och att testa minskningsprocesserna, särskilt i produktion.

Välj rätt mått

Det kan vara svårt att utforma mått. Ett vanligt misstag är att ta med för många mått för att undvika att missa något. Men detta kan leda till att du ignorerar eller misstror värdet för mått som inte uppfyller ett specifikt behov. I stället tar Microsoft-team tid att fastställa vilka data de behöver för att mäta framgång. Teams kan lägga till eller ändra mått, men att förstå syftet från början underlättar den processen.

Förutom grunden för ett mått överväger teamen vad de behöver måttet för att mäta. Till exempel kan hastigheten eller accelerationen av användarvinster vara ett mer användbart mått än det totala antalet användare. Måtten varierar från projekt till projekt, men de mest användbara är de som har potential att driva affärsbeslut.

Använda mått för att vägleda arbetet

Microsoft inkluderar mått i sina recensioner på högsta ledarskapsnivå. Var sjätte vecka presenterar organisationer hur de mår när det gäller hälsa, företag, scenarier och kundtelemetri. Organisationer diskuterar måtten med chefer och med sina team.

Team i hela organisationen undersöker engagerade användarmått för att fastställa innebörden av deras funktioner. Team skickar inte bara funktioner, utan tittar på om och hur människor använder dem. Team använder dessa mått för att justera kvarvarande uppgifter och avgöra om funktioner behöver mer arbete för att uppfylla målen.

Riktlinjer för leverans

• Det är aldrig en rak linje för att komma från A till B, och B är inte slutet.
• Det kommer alltid att finnas bakslag och misstag.
• Visa motgångar som inlärningsmöjligheter för att ändra taktik för att slutföra en viss del av processen.
• Med tiden utvecklar varje team sina DevOps-metoder genom att bygga vidare på erfarenhet och anpassa sig efter föränderliga behov.
• Nyckeln är att fokusera på att leverera värde, både till slutanvändare och själva leveransprocessen.