Aanbevelingen voor het ontwerpen van een toeleveringsketen voor de ontwikkeling van workloads
Van toepassing op deze aanbeveling voor de Well-Architected Operational Excellence-checklist: Power Platform
| OE:06 | Bouw een toeleveringsketen voor de workload die voorgestelde veranderingen aanstuurt via voorspelbare, geautomatiseerde pijplijnen. De pijplijnen testen en bevorderen deze veranderingen in verschillende omgevingen. Optimaliseer een toeleveringsketen om uw workload betrouwbaar, veilig, kosteneffectief en performant te maken. |
|---|
In deze handleiding worden de aanbevelingen beschreven voor het ontwerpen van een toeleveringsketen voor de ontwikkeling van workloads die is gebaseerd op pijplijnen voor continue integratie en continue levering (CI/CD). In cloudworkloads is een toeleveringsketen een gestandaardiseerde reeks tools en processen die u gebruikt om configuratie- en workloadveranderingen in verschillende omgevingen te beïnvloeden. Ontwikkel een toeleveringsketen om ervoor te zorgen dat u over een voorspelbare, gestandaardiseerde methode beschikt om uw workload te onderhouden. CI/CD-pijplijnen vormen de manifestatie van de toeleveringsketen, maar u moet één toeleveringsketen hebben. Het kan zijn dat u meerdere pijplijnen hebt die volgen dezelfde processen uitvoeren en dezelfde hulpmiddelen gebruiken.
Integreer een toeleveringsketen om uw workload te beschermen tegen schade die kan optreden als u veranderingen in de workload niet goed beheert. Wees u altijd bewust van de status van uw werklast, zodat u niet het risico loopt op onvoorspelbaar gedrag. Dit risico wordt nog groter als u kostbare tijd moet besteden aan het achterhalen van niet-verantwoorde wijzigingen wanneer er problemen ontstaan. Om deze risico's te minimaliseren, standaardiseert u de processen en tools waarmee uw toeleveringsketen wordt gedefinieerd, en zorgt u ervoor dat uw workloadteam zich volledig inzet voor het gebruik ervan.
Belangrijke ontwerpstrategieën
De volgende aanbevelingen kunnen u helpen de kernprincipes van uw toeleveringsketen te definiëren.
Breng voorgestelde wijzigingen in de workload aan door middel van toeleveringsketenprocessen en -tools. Dwing een strikt beleid af van geautomatiseerde, op sjablonen gebaseerde implementaties. Met deze methode wordt ervoor gezorgd dat de configuratie van uw workload in alle omgevingen gestandaardiseerd, goed gedefinieerd en strak gecontroleerd is. Voor omgevingen in een codepromotieketen mag u geen updates uitvoeren met behulp van handmatige processen of menselijke interactie. Neem alle wijzigingen in de omgeving op via een pijplijn door de implementatiepraktijken te volgen die u definieert. Om dit beleid te helpen afdwingen, kunt u overwegen de toegang standaard te beperken tot alleen-lezen en een toegangsautorisatiepoort te gebruiken om schrijftoegang toe te staan.
Een belangrijk aspect van dit principe is dat alle wijzigingen voorgestelde wijzigingen zijn totdat ze in productie worden geïmplementeerd. Door middel van geautomatiseerde tests, zoals integratie- en rooktests, stelt u uw toeleveringsketen in staat wijzigingen automatisch af te wijzen.
Gebruik één set codeactiva en artefacten voor alle omgevingen en pijplijnen. Een veelvoorkomend pijnpunt voor organisaties is wanneer niet-productieomgevingen verschillen van productieomgevingen. Het handmatig bouwen van productie- en niet-productieomgevingen kan resulteren in niet-overeenkomende configuraties tussen de omgevingen. Hierdoor wordt het testen vertraagd en is het waarschijnlijker dat veranderingen een productiesysteem kunnen schaden.
Laat uw organisatiestructuur in uw toeleveringsketen- en pijplijnontwerpen terugkomen. Het kan zijn dat uw organisatie geïsoleerd tussen teams zit. Elk team beheert mogelijk een deel van de toeleveringsketen. Veel organisaties hebben bijvoorbeeld teams die beveiligings- en compliance-instellingen of omgevingsconfiguraties beheren. Deze teams staan los van de ontwikkelingsteams die de ontwikkeling, het testen en de implementatie van toepassingen beheren. Er zijn veel manieren om de teams te organiseren die betrokken zijn in een toeleveringsketen. Uw toeleveringsketen is afhankelijk van de naadloze samenwerking van alle teams. Zorg ervoor dat alle teams standaardprocessen volgen en standaardtools gebruiken om de toeleveringsketen zo efficiënt mogelijk te maken.
Uw toeleveringsketen is mogelijk afhankelijk van externe leveranciers als u delen van de levenscyclus van de werklast uitbesteedt. Deze leveranciers zijn.Net zo belangrijk voor het succes van uw toeleveringsketen als interne middelen. Zorg ervoor dat alle teams het eens zijn over de processen en hulpmiddelen die u gebruikt.
Standaardiseer uw implementatiemethode. Praat met de producteigenaar over de aanvaardbare hoeveelheid productiedowntime voor uw workload. Afhankelijk van hoeveel en of downtime acceptabel is, kunt u de implementatiemethode kiezen die het beste bij uw vereisten past. Idealiter voert u implementaties uit tijdens een onderhoudsvenster om de complexiteit en risico's te verminderen.
Plan een holistische teststrategie. Een van de kernprincipes van systeembetrouwbaarheid is het 'shift left'-principe. Het ontwikkelen en implementeren van een toepassing is een proces dat wordt weergegeven als een reeks stappen die van links naar rechts gaan. U moet het testen niet beperken tot het einde van het proces. Verplaats het testen zoveel mogelijk naar het begin of naar links. Fouten zijn goedkoper te repareren als u ze vroegtijdig ontdekt. Ze kunnen duur zijn of later in de levenscyclus van de applicatie niet meer te herstellen.
Gebruik indien mogelijk geautomatiseerde tests om consistentie te garanderen. Neem de volgende soorten tests op in uw toeleveringsketenontwerp:
Unit-testen: unit-testen worden doorgaans uitgevoerd als onderdeel van een continue integratieroutine. Eenheidstests moeten uitgebreid en snel zijn. Idealiter dekken ze 100 procent van de code. Pas eenheidstests toe op alle codeactiva, inclusief sjablonen en scripts.
Rooktesten: Met rooktesten wordt gecontroleerd of een workload bestand is tegen een test omgeving en presteert zoals verwacht. Met rooktests wordt de interoperabiliteit van onderdelen niet geverifieerd. Met rooktests wordt geverifieerd dat de implementatiemethodologie voor de infrastructuur en de toepassing werkt, en dat het systeem reageert zoals bedoeld nadat het proces is voltooid.
Integratietesten: Integratietesten zorgen ervoor dat de applicatiecomponenten afzonderlijk functioneren. Vervolgens wordt bepaald of de componenten op de juiste manier met elkaar kunnen communiceren. Het kan een aanzienlijke hoeveelheid tijd in beslag nemen om een groot integratietestpakket uit te voeren. Daarom is het het beste om het shift-left-principe toe te passen en vroeg in de softwareontwikkelingscyclus testen uit te voeren. Reserveer integratietests voor scenario's die u niet kunt testen met een rooktest of eenheidstest. Indien nodig kunt u langlopende testprocessen met regelmatige tussenpozen uitvoeren. Een regelmatig interval biedt een goed compromis en detecteert interoperabiliteitsproblemen tussen toepassingsonderdelen uiterlijk één dag nadat ze zijn geïntroduceerd. Bij sommige testscenario's worden handmatige uitvoeringen ingezet. Gebruik handmatige tests wanneer u elementen van menselijke interactiviteit in tests moet introduceren.
Acceptatietesten: Afhankelijk van de context kunt u handmatig acceptatietesten uitvoeren. Dit kan gedeeltelijk of volledig geautomatiseerd zijn. Acceptatietests bepalen of het softwaresysteem voldoet aan de vereistespecificaties. Het hoofddoel van deze test is om te beoordelen of het systeem voldoet aan de zakelijke vereisten en om te bepalen of het systeem voldoet aan de vereiste criteria voor levering aan gebruikers.
Implementeer kwaliteitspoorten in uw codepromotieproces door middel van testen. Implementeer uw code in lagere omgevingen, zoals kwaliteitsborging en tests, en hoger in hogere omgevingen, zoals fasering en productie. Wanneer uw implementatie de kwaliteitspoorten passeert, moet u ervoor zorgen dat deze aan uw kwaliteitsdoelstellingen voldoet voordat de wijzigingen in productie gaan. Uw zakelijke vereisten bepalen waar de focus van uw kwaliteitspoorten ligt. Houd ook rekening met de fundamentele Well-Architected-principes: beveiliging, betrouwbaarheid en prestatie-efficiëntie. Power Platform
Integreer ook goedkeuringswerkstromen in uw kwaliteitspoorten. Definieer goedkeuringswerkstromen duidelijk en automatiseer ze indien van toepassing. Definieer kwaliteitsacceptatiecriteria in uw automatisering, zodat u efficiënt en veilig door uw poorten kunt bewegen.
Power Platform-facilitering
Pipelines zijn bedoeld om Application Lifecycle Management (ALM) te democratiseren voor Power Platform - en Dynamics 365-klanten door ALM-automatisering en CI/CD-mogelijkheden (Continuous Integration and Continuous Delivery) in de service te integreren. Power Platform
Microsoft Power Platform Build Tools voor Azure DevOps kunnen worden gebruikt om algemene build- en implementatietaken te automatiseren die betrekking hebben op apps die zijn gebouwd op Power Platform.
Met GitHub Actions kunnen ontwikkelaars geautomatiseerde workflows voor de levenscyclus van softwareontwikkeling bouwen. Power Platform Met GitHub-acties voor Microsoft Power Platform kunt u werkstromen in uw opslagplaats maken om apps te bouwen, te testen, te verpakken, vrij te geven, te implementeren, automatisering uit te voeren en bots en andere onderdelen gebouwd op Power Platform te beheren.
ALM Accelerator is een open-sourcetool die bestaat uit een set applicaties, scripts en pijplijnen die zijn ontworpen om het continue integratie-/continue leveringsproces te automatiseren.
Automatiseer tests met Azure Pipelines.
Power Apps checker Web API biedt een mechanisme om statische analysecontroles uit te voeren op aanpassingen en uitbreidingen van het Microsoft Dataverse platform.
Microsoft Power Platform CLI (PAC CLI) is een opdrachtregeltool die het importeren en exporteren van Power Platform oplossingen en het inpakken en uitpakken van Power Platform bronbestanden van oplossingen ondersteunt. PAC CLI is beschikbaar als een zelfstandige opdrachtregeltool of als een extensie voor Visual Studio Code.
U kunt Terraform, Bicep en Azure Resource Manager gebruiken voor onveranderlijke IaC-implementaties (Infrastructure as Code). Afhankelijk van uw vereisten en de bekendheid van uw team met de tools kunt u een of meer van deze tools gebruiken voor uw implementaties en het beheer van de resources.
Organisatorische afstemming
Cloud Adoption Framework biedt richtlijnen voor centrale teams bij het bieden van landingszones voor workloads. De workload-landingszones zijn de plekken waar de aangepaste toeleveringsketen van de workload applicaties implementeert.
Meer informatie vindt u in Wat is een Azure-landingszone? en de ontwerpprincipes voor Azure-landingszones.