Omgevingen
Gebruik het continue leveringsproces om snel en veilig nieuwe waarde te leveren aan productie. U kunt kleine wijzigingen vaak doorvoeren, waardoor het risico op problemen wordt verminderd.
Andere factoren zijn van invloed op 'implementatiepijn voor productie', waaronder uw acceptatie van meerdere leverings-/implementatieomgevingen. Met een multi-omgevingsbenadering kunt u code bouwen, testen en vrijgeven met een grotere snelheid en frequentie om uw implementatie zo eenvoudig mogelijk te maken. U kunt handmatige overhead en het risico van een handmatige release verwijderen en in plaats daarvan de ontwikkeling automatiseren met een proces met meerdere fasen dat gericht is op verschillende omgevingen.
Een algemene multi-omgevingsarchitectuur bevat vier lagen:
- Ontwikkeling
- Testen
- Staging
- Productie
In deze architectuur gaat uw product over op volgorde van Ontwikkeling (de omgeving waarin u wijzigingen in de software ontwikkelt) via Productie (de omgeving waarmee uw gebruikers rechtstreeks communiceren). U kunt ook een UAT-omgeving (User Acceptance Test) introduceren om de end-to-end bedrijfsstroom te valideren.
| Environment | Omschrijving |
|---|---|
| Ontwikkeling | Uw ontwikkelomgeving (dev) is de plek waar wijzigingen in software worden ontwikkeld. |
| Testen | Met uw testomgeving kunnen menselijke testers of geautomatiseerde tests nieuwe en bijgewerkte code uitproberen. Ontwikkelaars moeten nieuwe code en configuraties accepteren via eenheidstests in uw ontwikkelomgeving voordat ze een of meer testomgevingen mogen invoeren. |
| Staging | Fasering is de plek waar u de laatste tests direct voorafgaand aan de implementatie in productie uitvoert. Elke faseringsomgeving moet een werkelijke productieomgeving zo nauwkeurig mogelijk spiegelen. |
| UAT | Door gebruikersacceptatietests (UAT) kunnen uw eindgebruikers of clients tests uitvoeren om het softwaresysteem te verifiëren/accepteren voordat een softwaretoepassing naar uw productieomgeving kan overstappen. |
| Productie | Uw productieomgeving (productie), ook wel live genoemd, is de omgeving waarmee uw gebruikers rechtstreeks communiceren. |
Ontwerpoverwegingen
Pas de volgende overwegingen toe op de ontwikkeling van Azure-landingszones en Azure-workloads:
- Testomgevingen zijn belangrijk omdat platformontwikkelaars wijzigingen kunnen testen voordat ze in productie worden geïmplementeerd, wat het risico voor levering in productie vermindert.
- Door uw omgevingen zo vergelijkbaar mogelijk te houden, kunt u eenvoudig omgevingsgerelateerde fouten vinden in de eerste fasen van het testen, waardoor de ontwikkel- en testsnelheid en betrouwbaarheid toenemen.
- Als er verschillen zijn in de configuratie van uw omgevingen, treedt 'configuratiedrift' op, wat kan leiden tot gegevensverlies, tragere implementaties en fouten.
- U kunt implementaties versnellen, de consistentie van de omgeving verbeteren en 'configuratiedrift' tussen omgevingen verminderen door infrastructuur als code (IaC) te gebruiken.
- Overweeg methoden zoals Canary of Blue-Green Deployments te gebruiken die nieuwe functies alleen beschikbaar maken voor een beperkt aantal testgebruikers in productie en helpen de tijd om vrij te geven in productie te verminderen.
- Gebruik controles op testresultaten om de overgang van code van ontwikkeling naar productie te beheren. U kunt deze besturingselementen automatiseren zodat mislukte tests voorkomen dat wijzigingen automatisch worden geïmplementeerd in de volgende omgeving.
- Laat aangewezen gebruikers pull-aanvragen controleren voordat code in productie wordt geïmplementeerd. Overweeg het gebruik van opslagplaatsen met vertakkingsstrategie om het beoordelingsproces te beheren.
- Vermijd silo's door alle ontwikkelaars toegang te geven tot alle omgevingen.
Workloads
Raadpleeg veelgestelde vragen over het beheren van omgevingen voor workloads voor meer informatie over het beheren van omgevingen voor workloads.
Azure-landingszones
Het gebruik van meerdere omgevingen voor een Implementatie van Een Azure Landing Zone is gebruikelijk wanneer een klant de effecten en resultaten van nieuwe Azure Policy-toewijzingen, Azure RBAC-roltoewijzingen, Microsoft Entra-groepslidmaatschappen, het maken van Azure-resources en meer wil testen.
In de testbenadering voor bedrijfsschaal worden twee verschillende acceptatiemethoden beschreven:
- Replicatie van de hiërarchie van beheergroepen in de Canary- en Productieomgeving
- Sandbox-abonnementen
Ongeacht welke benadering u volgt, moet u altijd:
- Ten minste één omgeving gebruiken om te testen.
- Gebruik gescheiden service-principals voor test- en productiedoeleinden om uw omgevingen te beschermen.
- Geautomatiseerde controles en goedkeuringen implementeren om wijzigingen te valideren en goedkeuren voordat een wijziging in een bepaalde omgeving wordt geïmplementeerd