Inzicht in omgevingen

Voltooid

Met implementatiewerkstromen kunt u de stappen in uw implementatieproces automatiseren. Vaak moet u de stappen uitvoeren in meerdere afzonderlijke omgevingen. In uw speelgoedbedrijf wilt u de wijzigingen in uw code controleren voordat u de wijzigingen in uw productieomgeving implementeert.

In deze les leert u hoe omgevingen in GitHub Actions u helpen uw eigen proces te ondersteunen.

Waarom hebt u meerdere omgevingen?

Implementatieprocessen brengen wijzigingen aan in uw Azure-resources, inclusief resources die in gebruik zijn. Het wijzigen van resources brengt een risico met zich mee, omdat de wijzigingen die u implementeert, zich mogelijk niet gedragen zoals verwacht. Mogelijk ontdekt u zelfs dat de wijzigingen uw huidige installatie verbreken.

Om het risico op problemen te minimaliseren, is het een goed idee om uw wijzigingen op een veilige manier uit te proberen voordat u ze in uw productieomgeving implementeert. U minimaliseert het risico door de wijzigingen in een niet-productieomgeving te implementeren.

Veel organisaties stellen meerdere niet-productieomgevingen in waar ze hun wijzigingen geleidelijk implementeren voordat ze worden uitgebracht in productie. Elke niet-productieomgeving dient een specifiek doel en heeft vaak specifieke kwaliteitspoorten waaraan moet worden voldaan om door te gaan naar de volgende omgeving. Als er iets misgaat, zoals een test mislukt, stopt de implementatie. Naarmate uw implementatie door elke omgeving gaat, neemt uw vertrouwen in de wijzigingen toe.

Algemene omgevingen zijn onder andere:

• Ontwikkeling: Een ontwikkelomgeving wordt doorgaans gebruikt door ontwikkelaars om hun wijzigingen in te proberen en om hun werk snel te herhalen.

  Ontwikkelomgevingen hebben vaak minimale besturingselementen, zodat teamleden eenvoudig ideeën kunnen uitproberen. U kunt een ontwikkelomgeving gebruiken om een bepaalde configuratie-instelling op een resource te testen of om te zien hoe u een nieuwe website met een back-enddatabase op een veilige manier kunt instellen. Veel van deze wijzigingen en proefversies gaan mogelijk niet verder in uw implementatieproces, omdat u de ideeën elimineert die niet slagen.

  In sommige teams kunt u zelfs een afzonderlijke ontwikkelomgeving instellen voor elk teamlid, zodat ze elkaar niet in de weg zitten terwijl ze aan nieuwe functies werken.

  Ontwikkelomgevingen worden ook wel sandbox-omgevingen genoemd.

• Test: Een testomgeving is ontworpen om handmatige of geautomatiseerde tests uit te voeren op basis van uw wijzigingen.

  Testomgevingen kunnen worden gebruikt in een proces voor continue integratie. Nadat u een wijziging in een testomgeving hebt geïmplementeerd, kunnen er geautomatiseerde tests op worden uitgevoerd. Als alle geautomatiseerde tests slagen, is de wijziging veilig om samen te voegen in de hoofdbranch van het project. Geautomatiseerde tests controleren meestal op de kernfunctionaliteit van het systeem, samen met zaken als beleidsschendingen in de zojuist geïmplementeerde resources.

  U kunt ook speciale testomgevingen maken voor specifieke soorten tests, zoals prestatie- en beveiligingstests.

• Integratie: Een integratieomgeving kan u helpen bij het testen van alle integratiepunten met andere systemen.

  U kunt end-to-end transacties simuleren in een integratieomgeving. Deze tests worden vaak automatisch uitgevoerd, maar veel organisaties voeren ook handmatige tests uit op deze omgeving.

  Integratieomgevingen worden ook wel SIT-omgevingen (System Integration Test) genoemd.

• Gebruikersacceptatietest: een UAT-omgeving (User Acceptance Test) wordt gebruikt voor handmatige validatie, meestal door zakelijke belanghebbenden in plaats van ontwikkelaars. Bij handmatige validatie doorloopt iemand de oplossing en controleert of deze zich gedraagt zoals verwacht en of deze voldoet aan de benodigde bedrijfsvereisten. Deze persoon keurt vervolgens de wijzigingen goed, zodat de implementatie kan worden voortgezet.

• Preproductie: een preproductieomgeving is vaak een spiegel van de productieomgeving, met dezelfde resource-SKU's en configuratie. Deze wordt gebruikt als laatste controle om te controleren hoe de productie-implementatie zich gedraagt tijdens en nadat de wijziging is toegepast. Het kan ook worden gebruikt om te controleren of er downtime wordt verwacht tijdens de productie-implementatie.

  Preproductieomgevingen worden ook wel faseringsomgevingen genoemd.

• Productie: Uw productieomgeving is de omgeving die eindgebruikers van de toepassing gebruiken. Het is uw live-omgeving die u zoveel mogelijk wilt beveiligen en actief wilt houden.

  In sommige organisaties hebt u mogelijk meerdere productieomgevingen. U hebt bijvoorbeeld productieomgevingen in verschillende geografische regio's of om verschillende groepen klanten te bedienen.

• Demo: Uw team kan ook demonstratieomgevingen (demo's) maken om de toepassing aan eindgebruikers weer te geven, voor gebruik in training of voor verkoopteams om bepaalde mogelijkheden aan potentiële klanten weer te geven. Mogelijk hebt u zelfs meerdere demo-omgevingen die verschillende doeleinden dienen. Een demo-omgeving is vaak een afgeslankte replica van uw productieomgeving, met valse klantgegevens.

Omgevingen in uw organisatie

U ziet mogelijk variaties van deze omgevingen. Sommige organisaties gebruiken slechts een paar omgevingen en sommigen gebruiken nog veel meer. Het aantal en het type omgeving dat u gebruikt, zijn afhankelijk van de oplossing die u implementeert, de grootte van het team dat de oplossing bouwt en het belang van de workload.

Soms heeft één omgeving de rol van verschillende omgevingen die eerder zijn vermeld. In andere gevallen hebt u mogelijk een complexe werkstroom die in meerdere omgevingen wordt geïmplementeerd, sommige parallel en op volgorde. Sommige organisaties verwijderen of de inrichting van omgevingen zelfs ongedaan maken wanneer ze niet meer worden gebruikt en implementeren ze vervolgens opnieuw wanneer ze in de toekomst nodig zijn.

Wat uw organisatie ook kiest als de lijst met omgevingen, het doel is om uw vertrouwen in een wijziging te verbeteren tijdens het doorlopen van uw implementatiewerkstroom. Wanneer een wijziging niet voldoet aan uw kwaliteitsvereisten, wilt u de implementatie van die wijziging kunnen stoppen in eventuele volgende omgevingen in de keten.

In uw speelgoedbedrijf besluit u te beginnen met een basisset omgevingen voor uw website. Naast uw productieomgeving maakt u één niet-productieomgeving met de naam Test:

U werkt uw werkstroom bij om uw Bicep-code te implementeren in uw testomgeving en voert er enkele basistests voor uit. Als deze inspanning slaagt, kunt u deze vervolgens implementeren in uw productieomgeving.

Werkstroomomgevingen

GitHub Actions heeft ook het concept van een omgeving. U maakt een GitHub Actions-omgeving die de omgeving vertegenwoordigt die u in Azure hebt. Wanneer u uw werkstroom in een YAML-bestand definieert, kunt u taken koppelen aan een specifieke omgeving. Met behulp van omgevingen krijgt u enkele extra functies in uw werkstroom.

Beveiligingsregels

Een omgeving in GitHub Actions kan beveiligingsregels hebben geconfigureerd. Telkens wanneer de omgeving wordt gebruikt in een taak in uw werkstroom, zorgt GitHub Actions ervoor dat aan deze regels wordt voldaan voordat de taak wordt uitgevoerd.

U kunt bijvoorbeeld handmatige beoordelingen configureren voor uw productieomgeving. Voordat een productie-implementatie wordt gestart, ontvangt de aangewezen revisor een melding. Deze persoon kan handmatig controleren of aan uw beleid en procedures wordt voldaan voordat de implementatie begint. De fiatteur kan bijvoorbeeld controleren of alles werkt zoals verwacht in de preproductieomgeving voordat ze de implementatie goedkeuren.

Daarnaast kunt u een geautomatiseerde controle uitvoeren om te controleren of de vertakking van uw wijziging afkomstig is. Als de wijziging zich niet in uw hoofdbranch bevindt, kunt u GitHub configureren om te voorkomen dat deze wordt geïmplementeerd in uw productieomgeving.

Geheimen

Met GitHub Actions kunt u geheimen opslaan die alleen kunnen worden gebruikt met een specifieke omgeving. Verderop in deze module vindt u meer informatie over geheimbeheer.

Implementatiegeschiedenis

GitHub Actions houdt de geschiedenis van de implementaties in een omgeving bij. Deze geschiedenis biedt u een eenvoudige manier om bij te houden wat er in de loop van de tijd gebeurt in de omgeving. Hiermee kunt u zelfs een implementatie traceren naar een doorvoer in uw opslagplaats. Deze functie kan handig zijn als u een probleem hebt met een implementatie en de wijziging moet identificeren die tot het probleem heeft geleid.

Omgevingen maken

U kunt een omgeving maken met behulp van de GitHub-webinterface.

Wanneer uw werkstroom verwijst naar een omgeving die niet bestaat, maakt GitHub Actions deze automatisch voor u. Deze functie kan van invloed zijn op de beveiliging van uw GitHub-opslagplaats, omdat in de nieuwe omgeving geen beveiligingsregels zijn geconfigureerd. U kunt het beste zelf een omgeving maken via de GitHub-webinterface, zodat u volledige controle hebt over de beveiliging.

Een implementatietaak koppelen aan een omgeving

In de definitie van uw implementatiewerkstroom kunt u verwijzen naar een omgeving met behulp van de environment eigenschap:

jobs:
  deploy:
    environment: Test
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3

In dit voorbeeld is de benoemde deploy taak gekoppeld aan de Test omgeving.

Omgevingen en verbindingen met Azure

Wanneer u meerdere omgevingen gebruikt, moet u elke omgeving onafhankelijk van de andere maken. De website van uw ontwikkelomgeving mag bijvoorbeeld geen toegang hebben tot een database in uw productieomgeving.

Hetzelfde principe geldt ook voor de implementatiewerkstroom. U moet afzonderlijke workloadidentiteiten maken voor elke omgeving. Na deze procedure voegt u nog een beveiligingslaag toe om ervoor te zorgen dat uw niet-productie-implementaties geen invloed hebben op uw productieomgeving.

Aan workloadidentiteiten moeten specifieke machtigingen worden toegewezen om alleen te implementeren in het abonnement en de resourcegroep die door die omgeving wordt gebruikt:

Belangrijk

Gebruik een afzonderlijke workloadidentiteit voor elke omgeving waarnaar u van plan bent te implementeren. Verdeel de workloadidentiteit de minimale machtigingen die nodig zijn om te implementeren in de omgeving, en geen andere machtigingen.

Het is ook een goed idee om uw omgevingen in Azure te scheiden. U moet minimaal een afzonderlijke resourcegroep maken voor elke omgeving. In veel situaties is het beter om afzonderlijke Azure-abonnementen te maken voor elke omgeving. Vervolgens kunt u meerdere resourcegroepen maken binnen het abonnement van elke omgeving.

Pas Azure-roltoewijzingen toe zodat gebruikers en workloadidentiteiten alleen toegang hebben tot de omgevingen waartoe ze toegang nodig hebben. En wees voorzichtig met het beperken van de toegang tot uw productieomgeving tot een kleine set personen en de identiteit van de implementatieworkload voor die omgeving.

Federatieve referenties voor omgevingen

Wanneer uw workloadidentiteit vanuit uw implementatiewerkstroom verbinding maakt met Azure, wordt een federatieve referentie gebruikt om zichzelf veilig te verifiëren zonder geheimen of sleutels. In eerdere modules in dit leertraject hebben uw federatieve referenties toegang verleend tot uw implementatiewerkstromen wanneer ze zijn geïmplementeerd vanuit de hoofdbranch van uw Git-opslagplaats.

Wanneer u in een omgeving in uw werkstroom implementeert, moet u een federatieve referentie gebruiken die is gericht op die omgeving.

In deze module bevat uw werkstroom verschillende taken, waarvan velen verbinding maken en implementeren in Azure. Sommige taken maken gebruik van omgevingen en sommige niet. U maakt dus twee federatieve referenties voor elk van uw workloadidentiteiten: één bereik voor de omgeving en één bereik voor de hoofdbranch .