Implementatie en testen voor bedrijfskritieke workloads in Azure
Mislukte implementaties en foutieve releases zijn veelvoorkomende oorzaken van toepassingsstoringen. Uw benadering van implementatie en testen speelt een cruciale rol in de algehele betrouwbaarheid van een bedrijfskritieke toepassing.
Implementatie en testen moeten de basis vormen voor alle toepassings- en infrastructuurbewerkingen om consistente resultaten te garanderen voor bedrijfskritieke workloads. Wees voorbereid om wekelijks, dagelijks of vaker te implementeren. Ontwerp uw CI/CD-pijplijnen (continue integratie en continue implementatie) om deze doelen te ondersteunen.
De strategie moet het volgende implementeren:
Strenge tests vóór de release. Updates mag geen defecten, beveiligingsproblemen of andere factoren veroorzaken die de status van de toepassing in gevaar kunnen brengen.
Transparante implementaties. Het moet mogelijk zijn om updates op elk gewenst moment uit te rollen zonder dat dit van invloed is op gebruikers. Gebruikers moeten hun interacties met de toepassing zonder onderbreking kunnen voortzetten.
Bewerkingen met hoge beschikbaarheid. Implementatie- en testprocessen en hulpprogramma's moeten maximaal beschikbaar zijn om de algehele betrouwbaarheid van toepassingen te ondersteunen.
Consistente implementatieprocessen. Dezelfde toepassingartefacten en processen moeten worden gebruikt voor het implementeren van de infrastructuur en toepassingscode in verschillende omgevingen. End-to-end automatisering is verplicht. Handmatige ingrepen moeten worden vermeden omdat ze betrouwbaarheidsrisico's kunnen veroorzaken.
Dit ontwerpgebied bevat aanbevelingen voor het optimaliseren van implementatie- en testprocessen met als doel downtime te minimaliseren en de status en beschikbaarheid van toepassingen te behouden.
Belangrijk
Dit artikel maakt deel uit van de serie bedrijfskritieke workloads van Azure Well-Architected Framework . Als u niet bekend bent met deze reeks, raden we u aan te beginnen met Wat is een bedrijfskritieke workload? .
Implementatie zonder downtime
Bekijk de volgende video voor een overzicht van implementatie zonder downtime.
Het bereiken van implementaties zonder downtime is een fundamenteel doel voor bedrijfskritieke toepassingen. Uw toepassing moet de hele dag en elke dag beschikbaar zijn, zelfs wanneer nieuwe releases tijdens kantooruren worden geïmplementeerd. Investeer uw inspanningen vooraf om implementatieprocessen te definiëren en te plannen om belangrijke ontwerpbeslissingen te nemen, zoals of resources als kortstondig moeten worden behandeld.
Als u een implementatie zonder downtime wilt bereiken, implementeert u een nieuwe infrastructuur naast de bestaande infrastructuur, test u deze grondig, zet u het verkeer van eindgebruikers over en gebruikt u pas de vorige infrastructuur. Andere procedures, zoals de architectuur voor schaaleenheden, zijn ook van belang.
De mission-critical online - en Azure Mission-Critical Connected-referentie-implementaties illustreren deze implementatiebenadering, zoals weergegeven in dit diagram:
Toepassingsomgevingen
Bekijk de volgende video voor een overzicht van aanbevelingen voor toepassingsomgevingen.
U hebt verschillende typen omgevingen nodig om implementatiebewerkingen te valideren en te fasen. De typen hebben verschillende mogelijkheden en levenscyclussen. Sommige omgevingen kunnen de productieomgeving weerspiegelen en een lange levensduur hebben, terwijl andere van korte duur zijn en minder mogelijkheden hebben dan productie. Door deze omgevingen vroeg in de ontwikkelingscyclus in te stellen, kunt u zorgen voor flexibiliteit, scheiding van productie- en preproductieassets en het grondig testen van bewerkingen voordat ze in de productieomgeving worden vrijgegeven. Alle omgevingen moeten zoveel mogelijk de productieomgeving weerspiegelen, hoewel u naar behoefte vereenvoudigingen kunt toepassen op lagere omgevingen. In dit diagram ziet u een essentiële architectuur:
Er zijn enkele veelvoorkomende overwegingen:
Onderdelen mogen niet worden gedeeld tussen omgevingen. Mogelijke uitzonderingen zijn downstream-beveiligingsapparaten, zoals firewalls en bronlocaties voor synthetische testgegevens.
Alle omgevingen moeten infrastructuur gebruiken als codeartefacten (IaC), zoals Terraform- of Azure Resource Manager-sjablonen (ARM).
Ontwikkelomgevingen
Bekijk de volgende video voor informatie over tijdelijke ontwikkelomgevingen en automatische functievalidatie.
Overwegingen bij het ontwerpen
Mogelijkheden. Lagere vereisten voor betrouwbaarheid, capaciteit en beveiliging zijn acceptabel voor ontwikkelomgevingen.
Levenscyclus. Ontwikkelomgevingen moeten worden gemaakt zoals vereist en bestaan voor een korte tijd. Kortere levenscyclussen helpen configuratiedrift van de codebasis te voorkomen en kosten te verlagen. Ontwikkelomgevingen delen ook vaak de levenscyclus van een functiebranch.
Dichtheid. Teams hebben meerdere omgevingen nodig om parallelle functieontwikkeling te ondersteunen. Ze kunnen naast elkaar bestaan binnen één abonnement.
Ontwerpaanbeveling
Bewaar de omgeving in een toegewezen abonnement met context die is ingesteld voor ontwikkelingsdoeleinden.
Gebruik een geautomatiseerd proces om code van een functiebranch naar een ontwikkelomgeving te implementeren.
Test- of faseringsomgevingen
Deze omgevingen worden gebruikt voor testen en validatie. Er worden veel testcycli uitgevoerd om te zorgen voor een foutloze implementatie naar productie. De juiste tests voor een bedrijfskritieke workload worden beschreven in de sectie Continue validatie en testen .
Overwegingen bij het ontwerpen
Mogelijkheden. Deze omgevingen moeten de productieomgeving weerspiegelen voor betrouwbaarheid, capaciteit en beveiliging. Als er geen productiebelasting is, gebruikt u een synthetische gebruikersbelasting om realistische metrische gegevens en waardevolle invoer voor statusmodellering te bieden.
Levenscyclus. Deze omgevingen hebben een korte levensduur. Ze moeten worden vernietigd nadat de testvalidaties zijn voltooid.
Dichtheid. U kunt veel onafhankelijke omgevingen uitvoeren in één abonnement. U moet ook overwegen om meerdere omgevingen te gebruiken, elk in een toegewezen abonnement.
Notitie
Bedrijfskritieke toepassingen moeten grondig worden getest.
U kunt verschillende testfuncties uitvoeren in één omgeving, en in sommige gevallen moet u dat doen. Als u bijvoorbeeld chaostests wilt uitvoeren om zinvolle resultaten te leveren, moet u de toepassing eerst onder belasting plaatsen, zodat u begrijpt hoe de toepassing reageert op geïnjecteerde fouten. Daarom worden chaostests en belastingstests doorgaans parallel uitgevoerd.
Ontwerpaanbeveling
Zorg ervoor dat ten minste één faseringsomgeving de productie volledig weerspiegelt om productie-achtige tests en validatie mogelijk te maken. De capaciteit binnen deze omgeving kan worden aangepast op basis van de uitvoering van testactiviteiten.
Genereer synthetische gebruikersbelasting om een realistische testcase te bieden voor wijzigingen in een van de omgevingen.
Notitie
De Mission Critical Online-referentie-implementatie biedt een voorbeeld van een gebruikersbelastingsgenerator.
Definieer het aantal faseringsomgevingen en hun doeleinden binnen de ontwikkelings- en releasecyclus.
Productieomgevingen
Overwegingen bij het ontwerpen
Mogelijkheden. De hoogste niveaus van betrouwbaarheid, capaciteit en beveiligingsfunctionaliteit voor de toepassing zijn vereist.
Levenscyclus. Hoewel de levenscyclus van de workload en de infrastructuur hetzelfde blijft, hebben alle gegevens, inclusief bewaking en logboekregistratie, speciaal beheer nodig. Beheer is bijvoorbeeld vereist voor back-up en herstel.
Dichtheid. Voor sommige toepassingen kunt u overwegen om verschillende productieomgevingen te gebruiken om tegemoet te komen aan verschillende clients, gebruikers of bedrijfsfuncties.
Ontwerpaanbeveling
Zorg voor een duidelijke governancegrens voor productie- en lagere omgevingen. Plaats elk omgevingstype in een toegewezen abonnement om dat doel te bereiken. Deze segmentatie zorgt ervoor dat het resourcegebruik in lagere omgevingen geen invloed heeft op productiequota. Toegewezen abonnementen stellen ook toegangsgrenzen in.
Kortstondige blauw/groene implementaties
Voor een blauw/groen implementatiemodel zijn ten minste twee identieke implementaties vereist. De blauwe implementatie is de actieve implementatie die gebruikersverkeer in productie verzorgt. De groene implementatie is de nieuwe implementatie die is voorbereid en getest om verkeer te ontvangen. Nadat de groene implementatie is voltooid en getest, wordt het verkeer geleidelijk omgeleid van blauw naar groen. Als de taakoverdracht is geslaagd, wordt de groene implementatie de nieuwe actieve implementatie. De oude blauwe implementatie kan vervolgens via een gefaseerd proces buiten gebruik worden gesteld. Als er echter problemen zijn in de nieuwe implementatie, kan deze worden afgebroken en kan verkeer in de oude blauwe implementatie blijven of ernaar worden omgeleid.
Azure Mission-Critical raadt een blauw/groene implementatiebenadering aan waarbij infrastructuur en toepassingen samen worden geïmplementeerd als onderdeel van een implementatiestempel. Het implementeren van een wijziging in de infrastructuur of toepassing resulteert dus altijd in een groene implementatie die beide lagen bevat. Met deze benadering kunt u het effect van de wijziging volledig testen en valideren ten opzichte van de infrastructuur en de toepassing end-to-end voordat u gebruikersverkeer ernaar omleidt. De aanpak verhoogt het vertrouwen in het vrijgeven van wijzigingen en maakt upgrades zonder downtime mogelijk, omdat compatibiliteitsproblemen met downstreamafhankelijkheden zoals het Azure-platform, resourceproviders en IaC-modules kunnen worden gevalideerd.
Overwegingen bij het ontwerpen
Technologische mogelijkheden. Profiteer van de ingebouwde implementatiefuncties in Azure-services. Azure App Service biedt bijvoorbeeld secundaire implementatiesites die kunnen worden gewisseld na een implementatie. Met Azure Kubernetes Service (AKS) kunt u een afzonderlijke podimplementatie op elk knooppunt gebruiken en de servicedefinitie bijwerken.
Implementatieduur. Het kan langer duren voordat de implementatie is voltooid, omdat de stempel de infrastructuur en toepassing bevat in plaats van alleen het gewijzigde onderdeel. Dit is echter acceptabel omdat het risico dat alle onderdelen niet werken zoals verwacht, de tijdsoverwegingen overschrijft.
Gevolgen voor de kosten. Er worden extra kosten in rekening gebracht vanwege de twee implementaties naast elkaar, die naast elkaar moeten bestaan totdat de implementatie is voltooid.
Verkeersovergang. Nadat de nieuwe implementatie is gevalideerd, moet het verkeer worden overgezet van de blauwe omgeving naar de groene omgeving. Deze overgang vereist indeling van gebruikersverkeer tussen de omgevingen. De overgang moet volledig geautomatiseerd zijn.
Levenscyclus. Bedrijfskritieke implementatiestempels moeten als kortstondig worden beschouwd. Als u zegels met een korte levensduur gebruikt, wordt er elke keer een nieuwe start gemaakt voordat resources worden ingericht.
Ontwerpaanbeveling
Een blauw-groene implementatiebenadering gebruiken om alle productiewijzigingen vrij te geven. Implementeer elke keer alle infrastructuur en de toepassing, voor elk type wijziging, om een consistente status en geen downtime te bereiken. Hoewel u omgevingen opnieuw kunt gebruiken, raden we dit niet aan voor bedrijfskritische workloads. Behandel elke regionale implementatiestempel als kortstondig met een levenscyclus die is gekoppeld aan die van één release.
Gebruik een globale load balancer, zoals Azure Front Door, om de automatische overgang van gebruikersverkeer tussen de blauwe en groene omgevingen te organiseren.
Als u verkeer wilt overzetten, voegt u een groen back-endeindpunt toe dat gebruikmaakt van een laag verkeer naar volumegewicht, zoals 10 procent. Nadat u hebt gecontroleerd of het lage verkeersvolume op de groene implementatie werkt en de verwachte toepassingsstatus biedt, verhoogt u geleidelijk het verkeer. Terwijl u dit doet, past u een korte opstartperiode toe om fouten te ondervangen die mogelijk niet onmiddellijk zichtbaar zijn.
Nadat al het verkeer is overgezet, verwijdert u de blauwe back-end uit bestaande verbindingen. Verwijder bijvoorbeeld de back-end uit de globale load balancer-service, verwijder wachtrijen en koppel andere koppelingen los. Dit helpt om de kosten voor het onderhouden van de secundaire productie-infrastructuur te optimaliseren en ervoor te zorgen dat nieuwe omgevingen vrij zijn van configuratiedrift.
Op dit moment moet u de oude en nu inactieve blauwe omgeving buiten gebruik stellen. Herhaal het proces voor de volgende implementatie met blauw en groen omgekeerd.
Implementatie binnen abonnementsbereik
Afhankelijk van de schaalvereisten van uw toepassing, hebt u mogelijk meerdere productieabonnementen nodig om als schaaleenheden te fungeren.
Bekijk de volgende video voor een overzicht van aanbevelingen voor het verkennen van abonnementen voor een bedrijfskritieke toepassing.
Overwegingen bij het ontwerpen
Schaalbaarheid. Voor grootschalige toepassingsscenario's met aanzienlijke verkeersvolumes ontwerpt u de oplossing om te schalen tussen meerdere Azure-abonnementen, zodat de schaallimieten van één abonnement de schaalbaarheid niet beperken.
Belangrijk
Het gebruik van meerdere abonnementen vereist extra CI/CD-complexiteit, die op de juiste manier moet worden beheerd. Daarom raden we meerdere abonnementen alleen aan in scenario's met extreme schaal, waarbij de limieten van één abonnement waarschijnlijk een beperking worden.
Omgevingsgrenzen. Implementeer productie-, ontwikkelings- en testomgevingen in afzonderlijke abonnementen. Deze procedure zorgt ervoor dat lagere omgevingen niet bijdragen aan schaallimieten. Het vermindert ook het risico dat updates van lagere omgevingen de productie vervuilen door een duidelijke beheer- en identiteitsgrens te bieden.
Governance. Wanneer u meerdere productieabonnementen nodig hebt, kunt u overwegen om een toegewezen toepassingsbeheergroep te gebruiken om beleidstoewijzing te vereenvoudigen via een beleidsaggregatiegrens.
Ontwerpaanbeveling
Implementeer elke regionale implementatiestempel in een toegewezen abonnement om ervoor te zorgen dat de abonnementslimieten alleen van toepassing zijn binnen de context van één implementatiestempel en niet voor de toepassing als geheel. Indien van toepassing kunt u overwegen om meerdere implementatiestempels binnen één regio te gebruiken, maar u moet deze implementeren in onafhankelijke abonnementen.
Plaats globale gedeelde resources in een toegewezen abonnement om een consistente implementatie van regionale abonnementen mogelijk te maken. Vermijd het gebruik van een gespecialiseerde implementatie voor de primaire regio.
Continue validatie en testen
Testen is een kritieke activiteit waarmee u de status van uw toepassingscode en -infrastructuur volledig kunt valideren. Met testen kunt u met name voldoen aan uw normen voor betrouwbaarheid, prestaties, beschikbaarheid, beveiliging, kwaliteit en schaal. Testen moet goed worden gedefinieerd en toegepast als onderdeel van uw toepassingsontwerp en DevOps-strategie. Testen is een belangrijk probleem tijdens het lokale ontwikkelaarsproces (de binnenste lus) en als onderdeel van de volledige DevOps-levenscyclus (de buitenste lus), die is wanneer code wordt gestart op het pad van releasepijplijnprocessen naar de productieomgeving.
Bekijk de volgende video voor een overzicht van continue validatie en testen.
Deze sectie is gericht op het testen van de buitenste lus. Hierin worden verschillende soorten tests beschreven.
| Testen | Beschrijving |
|---|---|
| Het testen van modules | Bevestigt dat de bedrijfslogica van de toepassing werkt zoals verwacht. Valideert het algehele effect van codewijzigingen. |
| Betrouwbaarheidstest | Identificeert of infrastructuur- en toepassingsonderdelen beschikbaar zijn en functioneren zoals verwacht. Normaal gesproken wordt slechts één virtuele gebruikerssessie getest. Het resultaat moet zijn dat het systeem reageert met verwachte waarden en gedrag. Veelvoorkomende scenario's voor betrouwbaarheidstests zijn het bereiken van het HTTPS-eindpunt van een webtoepassing, het uitvoeren van query's op een database en het simuleren van een gebruikersstroom in de toepassing. |
| Gebruikersinterface testen | Valideert of gebruikersinterfaces van toepassingen zijn geïmplementeerd en of interacties met de gebruikersinterface naar verwachting functioneren. U moet hulpprogramma's voor ui-automatisering gebruiken om automatisering te stimuleren. Tijdens een ui-test moet een script een realistisch gebruikersscenario nabootsen en een reeks stappen uitvoeren om acties uit te voeren en een beoogde resultaat te bereiken. |
| Belasting testen | Valideert schaalbaarheid en toepassingsbewerking door de belasting snel en/of geleidelijk te verhogen totdat een vooraf vastgestelde drempelwaarde is bereikt. Belastingstests zijn doorgaans ontworpen rond een bepaalde gebruikersstroom om te controleren of aan de toepassingsvereisten wordt voldaan onder een gedefinieerde belasting. |
| Stresstests | Hiermee worden activiteiten toegepast die bestaande resources overbelasten om oplossingslimieten te bepalen en te controleren of het systeem probleemloos kan herstellen. Het belangrijkste doel is het identificeren van mogelijke prestatieknelpunten en schaallimieten. Omgekeerd moet u de computerresources van het systeem omlaag schalen en controleren hoe het zich gedraagt onder belasting en bepalen of het kan worden hersteld. |
| Prestaties testen | Combineert aspecten van belastings- en stresstests om prestaties onder belasting te valideren en benchmarkgedrag voor toepassingsbewerkingen vast te stellen. |
| Chaos testen | Injecteert kunstmatige fouten in het systeem om te evalueren hoe het reageert en om de effectiviteit van tolerantiemaatregelen, operationele procedures en risicobeperkingen te valideren. Het afsluiten van infrastructuuronderdelen, het opzettelijk verslechteren van de prestaties en het introduceren van toepassingsfouten zijn voorbeelden van tests die kunnen worden gebruikt om te controleren of de toepassing reageert zoals verwacht wanneer de scenario's zich daadwerkelijk voordoen. |
| Indringingstests | Zorgt ervoor dat een toepassing en de bijbehorende omgeving voldoen aan de vereisten van een verwachte beveiligingspostuur. Het doel is om beveiligingsproblemen te identificeren. Beveiligingstests kunnen end-to-end softwareleverings- en pakketafhankelijkheden omvatten, met scannen en controleren op bekende veelvoorkomende beveiligingsproblemen en blootstellingen (CVE). |
Overwegingen bij het ontwerpen
Automatisering. Geautomatiseerd testen is essentieel om wijzigingen in toepassingen of infrastructuur tijdig en herhaalbaar te valideren.
Testvolgorde. De volgorde waarin tests worden uitgevoerd, is een kritieke overweging vanwege verschillende afhankelijkheden, zoals de noodzaak om een actieve toepassingsomgeving te hebben. De testduur is ook van invloed op de volgorde. Tests met kortere uitvoeringstijden moeten indien mogelijk eerder in de cyclus worden uitgevoerd om de testefficiëntie te verhogen.
Schaalbaarheidslimieten. Azure-services hebben verschillende zachte en harde limieten. Overweeg belastingstests te gebruiken om te bepalen of een systeem het risico loopt deze te overschrijden tijdens de verwachte productiebelasting. Belastingstests kunnen ook handig zijn voor het instellen van de juiste drempelwaarden voor automatisch schalen. Voor services die geen ondersteuning bieden voor automatisch schalen, kan belastingstest u helpen geautomatiseerde operationele procedures af te stemmen.
Het kan beperkend zijn om systeemonderdelen, zoals actieve/passieve netwerkonderdelen of databases, op de juiste manier te schalen. Stresstests kunnen helpen bij het identificeren van beperkingen.
Analyse van foutmodus. Het introduceren van fouten in de toepassing en de onderliggende infrastructuur en het evalueren van het effect is essentieel voor het beoordelen van de redundantiemechanismen van de oplossing. Identificeer tijdens deze analyse het risico, de impact en de breedte van de impact (gedeeltelijke of volledige storing). Zie Uitvalrisico's van afzonderlijke onderdelen voor een voorbeeldanalyse die is gemaakt voor de referentie-implementatie van Mission Critical Online.
Bewaking. U moet testresultaten afzonderlijk vastleggen en analyseren en deze ook aggregeren om trends in de loop van de tijd te beoordelen. U moet de testresultaten voortdurend evalueren op nauwkeurigheid en dekking.
Ontwerpaanbeveling
Bekijk de volgende video om te zien hoe tolerantietests kunnen worden geïntegreerd met CI/CD-pijplijnen van Azure DevOps.
Zorg voor consistentie door alle tests op infrastructuur- en toepassingsonderdelen te automatiseren. Integreer de tests in CI/CD-pijplijnen om ze waar van toepassing te organiseren en uit te voeren. Zie DevOps-hulpprogramma's voor informatie over technologieopties.
Behandel alle testartefacten als code. Ze moeten worden onderhouden en versiebeheer samen met andere toepassingscodeartefacten.
Stem de SLA van de testinfrastructuur af met de SLA voor implementatie- en testcycli.
Voer betrouwbaarheidstests uit als onderdeel van elke implementatie. Voer ook uitgebreide belastingstests uit, samen met stress- en chaostests om te controleren of de prestaties en operabiliteit van de toepassing behouden blijven.
- Gebruik belastingprofielen die werkelijke piekgebruikspatronen weerspiegelen.
- Voer chaos-experimenten en mislukte injectietests uit op hetzelfde moment als belastingstests.
Tip
Azure Chaos Studio is een systeemeigen suite met hulpprogramma's voor chaos-experimenten. De hulpprogramma's maken het eenvoudig om chaos-experimenten uit te voeren en fouten in Azure-services en toepassingsonderdelen te injecteren.
Chaos Studio biedt ingebouwde chaos-experimenten voor veelvoorkomende foutscenario's en ondersteunt aangepaste experimenten die zijn gericht op infrastructuur en toepassingsonderdelen.
Als database-interacties, zoals het maken van records, vereist zijn voor belastings- of betrouwbaarheidstests, gebruikt u testaccounts met beperkte bevoegdheden en kunt u testgegevens scheiden van echte gebruikersinhoud.
Scan en bewaak de end-to-end softwareleveringsketen en pakketafhankelijkheden voor bekende CVE's.
- Gebruik Dependabot voor GitHub-opslagplaatsen om ervoor te zorgen dat de opslagplaats automatisch up-to-date is met de nieuwste releases van pakketten en toepassingen waarvan deze afhankelijk is.
Infrastructuur als code-implementaties
Infrastructuur als code (IaC) behandelt infrastructuurdefinities als broncode die samen met andere toepassingsartefacten wordt beheerd door de versie. Het gebruik van IaC bevordert codeconsistentie in omgevingen, elimineert het risico op menselijke fouten tijdens geautomatiseerde implementaties en biedt traceerbaarheid en terugdraaiactie. Voor blauw-groene implementaties is het gebruik van IaC met volledig geautomatiseerde implementaties noodzakelijk.
Een bedrijfskritieke IaC-opslagplaats heeft twee verschillende definities die zijn toegewezen aan globale en regionale resources. Zie het hoofdarchitectuurpatroon voor informatie over deze typen resources.
Overwegingen bij het ontwerpen
Herhaalbare infrastructuur. Bedrijfskritieke workloads implementeren op een manier die elke keer dezelfde omgeving genereert. IaC moet het primaire model zijn.
Automatisering. Alle implementaties moeten volledig geautomatiseerd zijn. Menselijke processen zijn foutgevoelig.
Ontwerpaanbeveling
Pas IaC toe om ervoor te zorgen dat alle Azure-resources worden gedefinieerd in declaratieve sjablonen en worden onderhouden in een opslagplaats voor broncodebeheer. Sjablonen worden geïmplementeerd en resources worden automatisch ingericht vanuit broncodebeheer via CI/CD-pijplijnen. Het gebruik van imperatieve scripts wordt afgeraden.
Handmatige bewerkingen voor alle omgevingen verbieden. De enige uitzondering zijn volledig onafhankelijke ontwikkelomgevingen.
DevOps-hulpprogramma's
Het effectieve gebruik van implementatiehulpprogramma's is essentieel voor de algehele betrouwbaarheid, omdat DevOps-processen van invloed zijn op het algehele functie- en toepassingsontwerp. Failover- en schaalbewerkingen kunnen bijvoorbeeld afhankelijk zijn van automatisering die wordt geleverd door DevOps-hulpprogramma's. Technische teams moeten inzicht hebben in het effect van het niet-beschikbaar zijn van een implementatieservice met betrekking tot de algehele workload. Implementatiehulpprogramma's moeten betrouwbaar en maximaal beschikbaar zijn.
Microsoft biedt twee azure-systeemeigen toolsets, GitHub Actions en Azure Pipelines, waarmee een bedrijfskritieke toepassing effectief kan worden geïmplementeerd en beheerd.
Overwegingen bij het ontwerpen
Technologische mogelijkheden. De mogelijkheden van GitHub en Azure DevOps overlappen elkaar. U kunt ze samen gebruiken om het beste van beide te krijgen. Een veelvoorkomende aanpak is het opslaan van codeopslagplaatsen in GitHub.com of GitHub AE tijdens het gebruik van Azure Pipelines voor implementatie.
Houd rekening met de complexiteit die wordt toegevoegd wanneer u meerdere technologieën gebruikt. Evalueer een uitgebreide functieset op basis van de algehele betrouwbaarheid.
Regionale beschikbaarheid. Wat de maximale betrouwbaarheid betreft, vormt de afhankelijkheid van één Azure-regio een operationeel risico.
Stel dat verkeer is verdeeld over twee regio's: Regio 1 en Regio 2. Regio 2 fungeert als host voor het Azure DevOps-hulpprogramma-exemplaar. Stel dat er een storing is in regio 2 en het exemplaar niet beschikbaar is. Regio 1 verwerkt automatisch al het verkeer en moet extra schaaleenheden implementeren om een goede failover-ervaring te bieden. Maar dit kan niet vanwege de Azure DevOps-afhankelijkheid in regio 2.
Gegevensreplicatie. Gegevens, waaronder metagegevens, pijplijnen en broncode, moeten tussen regio's worden gerepliceerd.
Ontwerpaanbeveling
Beide technologieën worden gehost in één Azure-regio, waardoor uw strategie voor herstel na noodgevallen beperkend kan zijn.
GitHub Actions is zeer geschikt voor buildtaken (continue integratie), maar heeft mogelijk geen functies voor complexe implementatietaken (continue implementatie). Gezien de uitgebreide functieset van Azure DevOps, raden we dit aan voor essentiële implementaties. U moet echter een keuze maken nadat u de afwegingen hebt beoordeeld.
Definieer een beschikbaarheids-SLA voor implementatiehulpprogramma's en zorg voor afstemming met bredere vereisten voor de betrouwbaarheid van toepassingen.
Voor scenario's met meerdere regio's die gebruikmaken van een actieve/passieve of actieve/actieve implementatieconfiguratie, moet u ervoor zorgen dat failover-indelings- en schaalbewerkingen kunnen blijven werken, zelfs als de primaire regio die als host fungeert voor implementatiehulpprogramma's niet meer beschikbaar is.
Vertakkingsstrategie
Er zijn veel geldige benaderingen voor vertakking. U moet een strategie kiezen die maximale betrouwbaarheid garandeert. Een goede strategie maakt parallelle ontwikkeling mogelijk, biedt een duidelijk pad van ontwikkeling naar productie en ondersteunt snelle releases.
Overwegingen bij het ontwerpen
Minimaliseer de toegang. Ontwikkelaars moeten hun werk doen in functie-/*- en fix-/*- vertakkingen. Deze vertakkingen worden toegangspunten voor wijzigingen. Op rollen gebaseerde beperkingen moeten worden toegepast op vertakkingen als onderdeel van de vertakkingsstrategie. Sta beheerders bijvoorbeeld alleen toe om releasevertakkingen te maken of naamconventies voor vertakkingen af te dwingen.
Versneld proces voor noodgevallen. De vertakkingsstrategie moet toestaan dat hotfixes worden samengevoegd met main zodra dit praktisch mogelijk is. Op die manier bevatten toekomstige releases de oplossing en wordt herhaling van het probleem vermeden. Gebruik dit proces alleen voor kleine wijzigingen die urgente problemen oplossen en gebruik het met terughoudendheid.
Ontwerpaanbeveling
Geef prioriteit aan het gebruik van GitHub voor broncodebeheer.
Belangrijk
Maak een vertakkingsstrategie die minimaal het werk van functies en releases in detail bevat, en gebruik beleidsregels en machtigingen voor vertakkingen om ervoor te zorgen dat de strategie op de juiste manier wordt afgedwongen.
Een geautomatiseerd testproces activeren om bijdragen aan codewijziging te valideren voordat ze worden geaccepteerd. Teamleden moeten ook wijzigingen controleren.
Behandel de hoofdvertakking als een continu voorwaartse en stabiele vertakking die voornamelijk wordt gebruikt voor integratietests.
- Zorg ervoor dat wijzigingen alleen in main worden aangebracht via pull-aanvragen. Gebruik een vertakkingsbeleid om directe doorvoeringen te verbieden.
- Telkens wanneer een pull-aanvraag wordt samengevoegd met main, wordt automatisch een implementatie gestart op basis van een integratieomgeving.
- De hoofdbranch moet als stabiel worden beschouwd. Het moet veilig zijn om op elk gewenst moment een release van de hoofdmap te maken.
Gebruik speciale release-/*- vertakkingen die zijn gemaakt op basis van de hoofdbranch en worden gebruikt om te implementeren in productieomgevingen. release/*- vertakkingen moeten in de opslagplaats blijven en kunnen worden gebruikt om een release te patchen.
Documenteer een hotfixproces en gebruik het alleen wanneer dat nodig is. Maak hotfixes in een fix/*- vertakking voor latere samenvoeging in de release-vertakking en implementatie naar productie.
AI voor DevOps
U kunt AIOps-methodologieën toepassen in CI/CD-pijplijnen als aanvulling op traditionele testmethoden. Hierdoor kunnen potentiële regressies of degradaties worden gedetecteerd en kunnen implementaties preventief worden gestopt om mogelijke negatieve gevolgen te voorkomen.
Overwegingen bij het ontwerpen
Volume van telemetriegegevens. CI/CD-pijplijnen en DevOps-processen verzenden een breed scala aan telemetrie voor machine learning-modellen. De telemetrie varieert van testresultaten en implementatieresultaten tot operationele gegevens over testonderdelen uit samengestelde implementatiefasen.
Schaalbaarheid. Traditionele gegevensverwerkingsmethoden, zoals Extraheren, Transformeren, Laden (ETL), kunnen de doorvoer mogelijk niet schalen om de groei van implementatietelemetrie en gegevens over de waarneembaarheid van toepassingen bij te houden. U kunt moderne analysemethoden gebruiken die geen ETL en gegevensverplaatsing vereisen, zoals gegevensvirtualisatie, om doorlopende analyse door AIOps-modellen mogelijk te maken.
Implementatiewijzigingen. Wijzigingen in de implementatie moeten worden opgeslagen voor geautomatiseerde analyse en correlatie met implementatieresultaten.
Ontwerpaanbeveling
Definieer de DevOps-procesgegevens die moeten worden verzameld en hoe deze moeten worden geanalyseerd. Telemetrie, zoals metrische gegevens over testuitvoering en tijdreeksgegevens van wijzigingen binnen elke implementatie, is belangrijk.
- Maak waarneembaarheidsgegevens van toepassingen beschikbaar vanuit faserings-, test- en productieomgevingen voor analyse en correlatie binnen AIOps-modellen.
Ontwikkel analytische modellen die context- en afhankelijkheidsbewust zijn om voorspellingen te bieden met geautomatiseerde functie-engineering om schema- en gedragswijzigingen aan te pakken.
Operationaliseer modellen door de best getrainde modellen binnen implementatiepijplijnen te registreren en te implementeren.
Volgende stap
Bekijk de beveiligingsoverwegingen.
Feedback
Binnenkort beschikbaar: In de loop van 2024 zullen we GitHub-problemen geleidelijk uitfaseren als het feedbackmechanisme voor inhoud en deze vervangen door een nieuw feedbacksysteem. Zie voor meer informatie: https://aka.ms/ContentUserFeedback.
Feedback verzenden en weergeven voor