Dela via

DevOps-mönster

  • Artikel

Koda från en enda plats och distribuera till flera mål i utvecklings-, test- och produktionsmiljöer som kan finnas i ditt lokala datacenter, privata moln eller det offentliga molnet.

Kontext och problem

Kontinuitet, säkerhet och tillförlitlighet för programdistribution är viktiga för organisationer och viktiga för utvecklingsteamen.

Appar kräver ofta omstrukturerad kod för att köras i varje målmiljö. Det innebär att en app inte är helt portabel. Den måste uppdateras, testas och verifieras när den flyttas genom varje miljö. Kod som skrivits i en utvecklingsmiljö måste till exempel skrivas om för att fungera i en testmiljö och skrivas om när den slutligen hamnar i en produktionsmiljö. Dessutom är den här koden specifikt kopplad till värden. Detta ökar kostnaden och komplexiteten med att underhålla din app. Varje version av appen är kopplad till varje miljö. Den ökade komplexiteten och dupliceringen ökar risken för säkerhet och kodkvalitet. Dessutom kan koden inte enkelt distribueras om när du tar bort återställningsvärdar som misslyckats eller distribuerar ytterligare värdar för att hantera ökad efterfrågan.

Lösning

Med DevOps-mönstret kan du skapa, testa och distribuera en app som körs i flera moln. Det här mönstret förenar den kontinuerliga integreringen och kontinuerlig leverans. Med kontinuerlig integrering skapas och testas kod varje gång en teammedlem genomför en ändring av versionskontrollen. Kontinuerlig leverans automatiserar varje steg från en version till en produktionsmiljö. Tillsammans skapar dessa processer en lanseringsprocess som stöder distribution i olika miljöer. Med det här mönstret kan du skapa koden och sedan distribuera samma kod till en lokal miljö, olika privata moln och offentliga moln. Skillnader i miljön kräver en ändring av en konfigurationsfil i stället för ändringar i koden.

DevOps pattern

Med en konsekvent uppsättning utvecklingsverktyg i lokala, privata moln och offentliga molnmiljöer kan du implementera en metod för kontinuerlig integrering och kontinuerlig leverans. Appar och tjänster som distribueras med DevOps-mönstret är utbytbara och kan köras på någon av dessa platser och dra nytta av lokala och offentliga molnfunktioner och funktioner.

Med hjälp av en DevOps-versionspipeline kan du:

  • Initiera en ny version baserat på kodincheckningar till en enda lagringsplats.
  • Distribuera automatiskt din nyligen skapade kod till det offentliga molnet för testning av användargodkännande.
  • Distribuera automatiskt till ett privat moln när koden har testats.

Problem och överväganden

DevOps-mönstret är avsett att säkerställa konsekvens mellan distributioner oavsett målmiljö. Funktionerna varierar dock mellan molnmiljöer och lokala miljöer. Tänk också på följande faktorer:

  • Är funktionerna, slutpunkterna, tjänsterna och andra resurser i distributionen tillgängliga på måldistributionsplatserna?
  • Lagras konfigurationsartefakter på platser som är tillgängliga i moln?
  • Kommer distributionsparametrar att fungera i alla målmiljöer?
  • Är resursspecifika egenskaper tillgängliga i alla målmoln?

Mer information finns i Utveckla Azure Resource Manager-mallar för molnkonsekvens.

Tänk också på följande när du bestämmer hur du ska implementera det här mönstret:

Skalbarhet

Distributionsautomatiseringssystem är den viktigaste kontrollpunkten i DevOps-mönstren. Implementeringar kan variera. Valet av rätt serverstorlek beror på storleken på den förväntade arbetsbelastningen. Virtuella datorer kostar mer att skala än containrar. Men om du vill använda containrar för skalning måste byggprocessen köras med containrar.

Tillgänglighet

Tillgänglighet i kontexten för DevPattern innebär att du kan återställa tillståndsinformation som är associerad med arbetsflödet, till exempel testresultat, kodberoenden eller andra artefakter. Överväg två vanliga mått vid utvärdering av tillgänglighetskraven:

  • Mål för återställningstid (RTO) anger hur länge du kan gå utan ett system.

  • Mål för återställningspunkt (RPO) anger hur mycket data du har råd att förlora om ett avbrott i tjänsten påverkar systemet.

I praktiken innebär RTO och RPO redundans och säkerhetskopiering. I det globala Azure-molnet är tillgänglighet inte en fråga om maskinvaruåterställning – det är en del av Azure – utan snarare om att se till att du behåller tillståndet för dina DevOps-system. Maskinvaruåterställning kan vara ett övervägande på Azure Stack Hub.

Ett annat stort övervägande när du utformar det system som används för distributionsautomatisering är åtkomstkontroll och korrekt hantering av de rättigheter som krävs för att distribuera tjänster till molnmiljöer. Vilka rättigheter krävs för att skapa, ta bort eller ändra distributioner? En uppsättning rättigheter krävs till exempel vanligtvis för att skapa en resursgrupp i Azure och en annan för att distribuera tjänster i resursgruppen.

Hanterbarhet

Utformningen av alla system som baseras på DevOps-mönstret måste överväga automatisering, loggning och aviseringar för varje tjänst i portföljen. Använd delade tjänster, ett programteam eller båda, och spåra även säkerhetsprinciper och styrning.

Distribuera produktionsmiljöer och utvecklings-/testmiljöer i separata resursgrupper på Azure eller Azure Stack Hub. Sedan kan du övervaka varje miljös resurser och samla in faktureringskostnader per resursgrupp. Du kan också ta bort resurser som en uppsättning, vilket är användbart för testdistributioner.

När du ska använda det här mönstret

Använd det här mönstret om:

  • Du kan utveckla kod i en miljö som uppfyller utvecklarnas behov och distribuera till en miljö som är specifik för din lösning där det kan vara svårt att utveckla ny kod.
  • Du kan använda den kod och de verktyg som utvecklarna vill, så länge de kan följa processen för kontinuerlig integrering och kontinuerlig leverans i DevOps-mönstret.

Det här mönstret rekommenderas inte:

  • Om du inte kan automatisera infrastruktur, etablering av resurser, konfiguration, identitet och säkerhetsuppgifter.
  • Om teamen inte har åtkomst till hybridmolnresurser för att implementera en CI/CD-metod (Continuous Integration/Continuous Development).

Nästa steg

Om du vill veta mer om ämnen som introduceras i den här artikeln:

När du är redo att testa lösningsexemplet fortsätter du med distributionsguiden för DevOps-hybrid-CI/CD-lösningen. Distributionsguiden innehåller stegvisa instruktioner för att distribuera och testa dess komponenter. Du lär dig hur du distribuerar en app till Azure och Azure Stack Hub med hjälp av en pipeline för kontinuerlig integrering/kontinuerlig leverans (CI/CD).