Inzicht in omgevingen

Voltooid

Met implementatiepijplijnen 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 Azure Pipelines u helpen uw eigen werkstroom 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 kunt de wijzigingen bijvoorbeeld implementeren in een niet-productieomgeving.

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 pijplijn 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 wanneer deze door uw implementatiepijplijn verloopt. 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 pijplijn bij om uw Bicep-code te implementeren in uw testomgeving en voert er enkele basistests voor uit. Als deze inspanning slaagt, wordt de code geïmplementeerd in uw productieomgeving.

Pijplijnomgevingen

Azure Pipelines heeft ook het concept van een omgeving. U maakt een Azure Pipelines-omgeving die de omgeving vertegenwoordigt die u in Azure hebt. Wanneer u uw pijplijn in een YAML-bestand definieert, koppelt u uw implementatietaken aan een specifieke omgeving. Door omgevingen te gebruiken, krijgt u enkele andere functies in uw pijplijn.

Controles en goedkeuringen

Een omgeving in Azure DevOps kan controles en goedkeuringen hebben geconfigureerd. Telkens wanneer de omgeving wordt gebruikt in een taak in uw pijplijn, zorgt Azure DevOps ervoor dat deze controles en goedkeuringen slagen voordat de taak wordt uitgevoerd.

U kunt bijvoorbeeld handmatige goedkeuringen configureren voor uw productieomgeving. Voordat een productie-implementatie wordt gestart, ontvangt de aangewezen fiatteur een e-mailmelding. 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 na de laatste implementatie een geautomatiseerde controle uitvoeren om de logboeken en foutpercentages in uw preproductieomgeving te bekijken. Als de controle bevestigt dat het aantal fouten niet aanzienlijk is toegenomen, kan de implementatie worden voortgezet.

Implementatiegeschiedenis

Azure Pipelines 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 specifieke functieaanvraag in uw Azure Boards-werkitems of naar een doorvoering 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.

Beveiliging

U kunt andere beveiligingscontroles toepassen op omgevingen. U kunt de pijplijnen beperken die een specifieke omgeving mogen gebruiken. Of voorkom dat iemand per ongeluk een secundaire pijplijn maakt die communiceert met uw productieomgeving.

U kunt ook gebruikersmachtigingen toepassen om de gebruikers te beheren die omgevingen kunnen beheren. Met specifieke machtigingen kunnen gebruikers nieuwe omgevingen maken, omgevingen wijzigen en omgevingen en de geschiedenis van implementaties bekijken.

Notitie

Wanneer uw pijplijn verwijst naar een omgeving die nog niet bestaat, maakt Azure Pipelines deze automatisch voor u. Deze functie kan van invloed zijn op de beveiliging van uw Azure DevOps-project, omdat u automatisch beheerdersmachtigingen voor de omgeving krijgt. U kunt het beste zelf een omgeving maken via de Azure DevOps-webinterface, zodat u volledige controle hebt over de beveiliging en u niet per ongeluk machtigingen krijgt die u niet nodig hebt.

Een implementatietaak koppelen aan een omgeving

In de definitie van de implementatiepijplijn maakt u een deployment eigenschap om een implementatietaak op te geven en geeft u de naam op van de omgeving waarin de taak wordt geïmplementeerd:

- stage: DeployTest
  displayName: Deploy (Test Environment)
  jobs:
  - deployment: DeployWebsite
    environment: Test
    strategy:
      runOnce:
        deploy:
          steps:
            - checkout: self

In het voorbeeld is de benoemde DeployWebsite taak gekoppeld aan de Test omgeving.

Tip

Taken hebben ook andere eigenschappen, waaronder de implementatiestrategie, die buiten het bereik van deze module vallen. We koppelen een koppeling naar meer informatie in de samenvattingseenheid.

Omgevingen en serviceverbindingen

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 implementatiepijplijn. De serviceverbinding die u gebruikt om te implementeren in uw ontwikkelomgeving, mag geen toegang hebben tot uw productieomgeving. Volgens dit principe voegt u nog een beveiligingslaag toe om ervoor te zorgen dat uw niet-productie-implementaties geen invloed hebben op uw productieomgeving.

U moet afzonderlijke serviceverbindingen maken voor elke omgeving. Elke serviceverbinding moet een eigen toegewezen service-principal gebruiken, met specifieke machtigingen om alleen te implementeren in het abonnement en de resourcegroep die door die omgeving wordt gebruikt:

Belangrijk

Gebruik een afzonderlijke service-principal en serviceverbinding voor elke omgeving waarnaar u van plan bent te implementeren. Verdeel de service-principal de minimale machtigingen die de service-principal nodig heeft 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 service-principals 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 service-principal voor de implementatie voor die omgeving.