Omgevingsstrategie voor ALM
Volgens de principes van ALM (Application Lifecycle Management) hebt u aparte omgevingen nodig voor de ontwikkeling en productie van apps. Hoewel u basis ALM kunt uitvoeren met alleen een afzonderlijke ontwikkel- en productieomgeving, raden we u aan ook ten minste één testomgeving te onderhouden die gescheiden is van uw ontwikkel- en productieomgeving. Als u een aparte testomgeving hebt, kunt u end-to-end validatie uitvoeren, inclusief de implementatie van de oplossing en het testen van de toepassing. Sommige organisaties hebben mogelijk ook meer omgevingen nodig voor gebruikersacceptatietesten (UAT), systeemintegratietesten (SIT) en training.
Afzonderlijke ontwikkelomgevingen kunnen nuttig zijn voor het isoleren van wijzigingen van één inspanning, die wordt ingecheckt voordat deze is voltooid. Afzonderlijke ontwikkelomgevingen kunnen ook nuttig zijn om situaties te verminderen waarin de wijzigingen van de ene persoon die van een andere negatief beïnvloeden.
Elke organisatie is uniek, dus denk goed na over wat de omgeving van uw organisatie nodig heeft.
Ontwikkelomgevingen
U moet vragen beantwoorden als:
- Hoeveel ontwikkelomgevingen heb ik nodig?
- Meer informatie: Overzicht van omgevingen
- Hoe kan ik omgevingen automatisch inrichten vanuit de broncode?
- Meer informatie: Microsoft Power Platform Build Tools voor Azure DevOps
- Wat zijn de afhankelijkheden van mijn omgevingen?
- Meer informatie: Meerdere oplossingslagen en afhankelijkheden
Andere omgevingen
U moet ook de vraag beantwoorden: 'Welke soorten niet-ontwikkelomgevingen heb ik nodig?'
Naast uw productieomgeving hebt u bijvoorbeeld mogelijk afzonderlijke test-, UAT-, SIT- en pre-productieomgevingen nodig. Merk op dat elke betrouwbare ALM-praktijk ten minste het gebruik van een testomgeving moet omvatten voordat iets in de productieomgeving wordt geïmplementeerd. Dit zorgt ervoor dat u een plek hebt om de app te testen, maar zorgt er ook voor dat de implementatie zelf getest kan worden.
Meer informatie: Een omgevingsstrategie ontwikkelen voor Microsoft Power Platform
Overwegingen ten aanzien van meerdere geografische locaties
Power Platform-omgevingen volgen een specifiek service-updateschema, aangezien omgevingen over de hele wereld worden bijgewerkt. Er zijn in totaal zes stations die voornamelijk worden bepaald door geografische locatie. Service-updates worden voor elk station in volgorde toegepast. Service-updates van station 2 worden dus toegepast vóór station 3. Daarom is het gebruikelijk dat omgevingen die zich op verschillende stations bevinden, op een bepaald moment verschillende versies hebben. Ga voor meer informatie over het service-updateschema voor omgevingen naar Uitgebrachte versies van Microsoft Dataverse
Import van oplossingen en omgevingsversie
Als u meerdere omgevingen in verschillende regio's hebt, is het belangrijk om het volgende te begrijpen wanneer u een oplossing importeert:
- U kunt een oplossing importeren in een omgeving die een nieuwere versie heeft dan de omgeving waar de oplossing is geëxporteerd.
- U kunt een oplossing niet veilig importeren in een omgeving die een oudere versie heeft dan de omgeving waar de oplossing is geëxporteerd. Dit komt omdat er mogelijk onderdelen of vereiste functionaliteit in de oudere omgeving ontbreken.
Voorbeeld van het succesvol afstemmen van omgevingen met service-updatestations
Stel u voor dat u productieomgevingen in Canada en de Verenigde Staten hebt. In dat geval moeten uw ontwikkelomgevingen zich in Noord-Amerika (station 5) bevinden en niet in Canada (station 2). Uw ontwikkelomgevingen hebben dan altijd dezelfde of een eerdere versie dan uw productieomgevingen, waardoor conflicten met de importversie van oplossingen worden beperkt.
