ALM-basisbeginselen met Microsoft Power Platform
Dit artikel beschrijft de onderdelen, tools en processen die nodig zijn om ALM (Application Lifecycle Management) te implementeren.
Omgevingen
Een omgeving is een ruimte waar de zakelijke gegevens, apps en bedrijfsprocessen van uw organisatie kunnen worden opgeslagen, beheerd en gedeeld. Een omgeving dient ook als een container om apps te scheiden die verschillende rollen, beveiligingsvereisten of doelgroepen hebben. Elke omgeving kan maar één Microsoft Dataverse-database hebben. Meer informatie: Overzicht van omgevingen
Belangrijk
Wanneer u een omgeving maakt, kunt u ervoor kiezen om Dynamics 365-apps te installeren, zoals Dynamics 365 Sales en Dynamics 365 Marketing. Het is belangrijk om op dat moment te bepalen of deze apps al dan niet vereist zijn, omdat ze niet later kunnen worden verwijderd of geïnstalleerd. Als u niet op deze apps voortbouwt en ze in de toekomst niet nodig zult hebben, raden we u aan ze niet in uw omgevingen te installeren. Dit helpt afhankelijkheidscomplicaties te voorkomen wanneer u oplossingen tussen omgevingen distribueert.
Soorten omgevingen die worden gebruikt in ALM
Met het Power Platform-beheercentrum kunt u de volgende typen Power Platform-omgevingen maken:
Sandbox: een sandboxomgeving is elke niet-productieomgeving van Dataverse. Omdat de omgeving is geïsoleerd van de productieomgeving, kunt u de sandbox-omgeving gebruiken om toepassingen te ontwikkelen en te testen met weinig risico. Sandboxomgevingen bevatten mogelijkheden die schadelijk zouden zijn in een productieomgeving, zoals reset-, verwijder- en kopieerbewerkingen. Meer informatie: Sandboxomgevingen beheren
Productie: de omgeving waar apps en andere software worden ingezet voor het beoogde gebruik.
Ontwikkelaar (officieel Community genoemd). Het Power Apps Developer-abonnment geeft u toegang tot de premium functionaliteit van Power Apps, Dataverse en Power Automate voor individueel gebruik. Dit abonnement is vooral bedoeld om Power Apps, Power Automate, en Microsoft Dataverse mee te bouwen en te testen of voor leerdoeleinden. Een ontwikkelaarsomgeving is een omgeving voor één gebruiker en kan niet worden gebruikt om productie-apps uit te voeren of te delen.
Standaard Er wordt automatisch één standaardomgeving voor elke tenant gemaakt die door alle gebruikers in die tenant wordt gedeeld. De tenant identificeert de klant en aan de klant kunnen een of meer Microsoft-abonnementen en -diensten zijn gekoppeld. Nieuwe gebruikers die zich aanmelden voor Power Apps worden automatisch toegevoegd aan de rol Maker van de standaardomgeving. De standaardomgeving wordt gemaakt in de regio die het dichtst bij de standaardregio van de Microsoft Entra-tenant ligt en krijgt de naam: '{Microsoft Entra-tenantnaam} (standaard)'
Maak en gebruik de juiste omgeving voor een specifiek doel, zoals ontwikkeling, test of productie.
Meer informatie over werken met omgevingen vindt u hier: Overzicht van omgevingen.
Wie moet toegang hebben?
Definieer en beheer de beveiliging van uw resources en gegevens in Microsoft Dataverse. Microsoft Power Platform biedt beheerdersrollen op omgevingsniveau om taken uit te voeren. Dataverse omvat de beveiligingsrollen die het toegangsniveau tot apps, app-onderdelen en -resources bepalen die app-makers en gebruikers hebben in Dataverse.
| Omgevingsdoel | Rollen die toegang hebben | Opmerkingen |
|---|---|---|
| Ontwikkeling | App-makers en ontwikkelaars. | App-gebruikers mogen geen toegang hebben. Ontwikkelaars hebben op zijn minst de beveiligingsrol Omgevingsmaker nodig om resources te kunnen maken. |
| Testen | Beheerders en mensen die testen. | App-makers, ontwikkelaars en gebruikers van productie-apps mogen geen toegang hebben. Testgebruikers moeten net voldoende bevoegdheden hebben om tests uit te voeren. |
| Productie | Beheerders en app-gebruikers. Gebruikers moeten net voldoende toegang hebben om hun taken uit te voeren voor de apps die ze gebruiken. | App-makers en ontwikkelaars mogen geen toegang hebben of mogen alleen bevoegdheden op gebruikersniveau hebben. |
| Standaardinstelling | Standaard kan elke gebruiker in uw tenant apps maken en bewerken in een Dataverse-standaardomgeving die een database heeft. | We raden u ten zeerste aan om omgevingen te maken voor een specifiek doel en de juiste rollen en bevoegdheden alleen toe te kennen aan de mensen die ze nodig hebben. |
Meer informatie:
- Overzicht van omgevingen
- Gebruikerstoegang tot omgevingen beheren: beveiligingsgroepen en licenties
- Gebruikers maken en beveiligingsrollen toewijzen
- Omgevingen maken
Oplossingen
Oplossingen worden gebruikt om apps en onderdelen van de ene omgeving naar de andere over te brengen of om een reeks aanpassingen toe te passen op bestaand apps.
Oplossingen hebben deze kenmerken:
Ze bevatten metagegevens en bepaalde entiteiten met configuratiegegevens. Oplossingen bevatten geen zakelijke gegevens.
Ze kunnen veel verschillende Microsoft Power Platform-onderdelen bevatten, zoals modelgestuurde apps, canvas-apps, siteoverzichten, stromen, entiteiten, formulieren, aangepaste connectors, webresources, optiesets, grafieken en velden. Merk op dat niet alle entiteiten in een oplossing kunnen worden opgenomen. De systeemtabellen Toepassingsgebruiker, Aangepaste API en Organisatie-instelling kunnen bijvoorbeeld niet aan een oplossing worden toegevoegd.
Ze zijn verpakt als een eenheid om te worden geëxporteerd en geïmporteerd naar andere omgevingen, of om te worden gedeconstrueerd en als broncode voor activa te worden ingecheckt in bronbeheer. Oplossingen worden ook gebruikt om wijzigingen toe te passen op bestaande oplossingen.
Beheerde oplossingen worden gebruikt om te worden geïmplementeerd in elke omgeving die geen ontwikkelomgeving is voor die oplossing. Hieronder vallen testomgevingen, UAT-omgevingen (gebruikersacceptatietest), SIT-omgevingen (systeemintegratietest) en productieomgevingen. Beheerde oplossingen kunnen onafhankelijk van andere beheerde oplossingen in een omgeving worden onderhouden (upgraden, patchen en verwijderen). Als best practice voor ALM moeten beheerde oplossingen worden gegenereerd door een build-server en worden beschouwd als een build-artefact.
Updates van een beheerde oplossing worden geïmplementeerd naar de vorige versie van de beheerde oplossing. Er wordt geen extra oplossingslaag gemaakt. U kunt geen onderdelen verwijderen met een update.
Een patch bevat alleen de wijzigingen voor een bovenliggende beheerde oplossing. Gebruik patches alleen bij kleine updates (vergelijkbaar met een hotfix) en u moet deze zo snel mogelijk verwijderen. Wanneer patches worden geïmporteerd, worden ze in een laag boven op de bovenliggende oplossing geïmplementeerd. U kunt geen onderdelen verwijderen met een patch.
Bij het upgraden van een oplossing wordt direct boven de basislaag en eventuele bestaande patches een nieuwe oplossingslaag geïnstalleerd.
Bij het toepassen van oplossingsupgrades worden alle bestaande patches en de basislaag verwijderd.
Oplossingenupgrades verwijderen onderdelen die bestonden, maar niet meer in de upgradeversie zijn opgenomen.
Meer informatie: Oplossingsconcepten
Bronbeheer
Bronbeheer, ook wel versiebeheer genoemd, is een systeem dat softwareontwikkelingsactiva onderhoudt en veilig opslaat en wijzigingen in die activa bijhoudt. Het bijhouden van wijzigingen is vooral belangrijk wanneer meerdere app-makers en ontwikkelaars aan dezelfde set bestanden werken. Een bronbeheersysteem biedt u ook de mogelijkheid om wijzigingen terug te draaien of verwijderde bestanden te herstellen.
Een bronbeheersysteem helpt organisaties met een betrouwbaar ALM omdat de activa die in het bronbeheersysteem worden onderhouden, de 'enige bron van waarheid' zijn, oftewel het enige toegangs- en wijzigingspunt voor uw oplossingen.
Strategie voor vertakken en samenvoegen
Bijna elk bronbeheersysteem heeft een vorm van ondersteuning voor vertakking en samenvoeging. Vertakken betekent dat u afwijkt van de hoofdlijn van ontwikkeling en doorgaat met werken zonder de hoofdlijn te veranderen. Samenvoegen betekent het combineren van twee vertakkingen, zoals een ontwikkelingstak die wordt samengevoegd met een hoofdlijntak. Enkele veelvoorkomende vertakkingsstrategieën zijn trunkvertakking, releasevertakking en functievertakking. Meer informatie: Een Git-vertakkingsstrategie aannemen
Bronbeheerproces met behulp van een oplossing
Er zijn twee hoofdpaden die u kunt gebruiken bij het werken met oplossingen in een bronbeheersysteem:
- Exporteer de onbeheerde oplossing en plaats deze als onverpakt in het bronbeheersysteem. Het build-proces importeert de verpakte oplossing als onbeheerd in een tijdelijke build-omgeving (sandboxomgeving). Exporteer de oplossing vervolgens als beheerd en sla deze als build-artefact op in uw bronbeheersysteem.
- Exporteer de oplossing als onbeheerd en exporteer de oplossing ook als beheerd. Plaats beide in het bronbeheersysteem. Hoewel deze methode geen build-omgeving vereist, moeten er wel twee exemplaren van alle onderdelen worden onderhouden (één exemplaar van alle onbeheerde onderdelen vanuit de onbeheerde oplossing en één exemplaar van alle beheerde onderdelen vanuit de beheerde oplossing).
Meer informatie: Taken van build-tools
Automatisering
Automatisering is een belangrijk onderdeel van de levenscyclus van toepassings. Deze verbetert de productiviteit, betrouwbaarheid, kwaliteit en efficiëntie van ALM. Automatiseringstools en -taken worden gebruikt om oplossingen te valideren, te exporteren, in te pakken, uit te pakken en te exporteren, en om sandboxomgevingen te maken en opnieuw in te stellen.
Meer informatie: Wat zijn Microsoft Power Platform Build Tools?
Teamontwikkeling met behulp van gedeeld bronbeheer
Het is belangrijk om na te denken over hoe u en uw ontwikkelingsteam zullen samenwerken om het project te bouwen. Door silo's af te breken en weergaven en gesprekken te bevorderen, kan uw team betere software leveren. Sommige tools en werkstromen, zoals die in Git, GitHub en Azure DevOps zijn ontworpen met het uitdrukkelijke doel de communicatie en softwarekwaliteit te verbeteren. Het werken met configuraties in een oplossingssysteem kan echter een uitdaging vormen voor teamontwikkeling. Organisaties moeten wijzigingen van meerdere ontwikkelaars beheren om samenvoegingsconflicten zoveel mogelijk te voorkomen, omdat bronbeheersystemen beperkingen hebben met betrekking tot hoe samenvoegingen worden uitgevoerd. We raden u aan situaties te vermijden waarin meerdere mensen tegelijkertijd wijzigingen aanbrengen in complexe onderdelen, zoals formulieren, stromen en canvas-apps.
Meer informatie: Scenario 5: Teamontwikkeling ondersteunen
Continue integratie en implementatie
In eerste instantie kunt u elk bronbeheersysteem gebruiken en een pijplijn bouwen voor continue integratie en continue implementatie (CI/CD). Deze gids richt zich echter op GitHub en Azure DevOps. GitHub is een ontwikkelingsplatform dat wordt gebruikt door miljoenen ontwikkelaars. Azure DevOps biedt ontwikkelaarsdiensten om teams te ondersteunen bij het plannen van werk, het samenwerken aan codeontwikkeling en het bouwen en implementeren van toepassingen.
Om aan de slag te kunnen, hebt u het volgende nodig:
Een GitHub-account, waar u een opslagplaats kunt maken. Als u geen account hebt, kunt u er gratis een maken.
een Azure DevOps-organisatie. Als u geen account hebt, kunt u er gratis een maken.
Meer informatie: Uw eerste pijplijn maken
Licenties
Om apps en stromen te maken of te bewerken met Power Apps en Power Automate, moeten gebruikers respectievelijk een licentie per gebruiker hebben voor Power Apps of Power Automate of een geschikte Dynamics 365-toepassingslicentie. Meer informatie vindt u in Overzicht van licenties voor Microsoft Power Platform. We raden u ook aan contact op te nemen met uw Microsoft-accountvertegenwoordiger om uw licentiebehoeften te bespreken.
ALM-overwegingen
Als u ALM beschouwt als een integraal onderdeel van het bouwen van apps op Microsoft Power Platform, kan het de snelheid, betrouwbaarheid en gebruikerservaring van de app drastisch verbeteren. Het zorgt er ook voor dat meerdere ontwikkelaars, zowel traditionele ontwikkelaars die code schrijven als niet-professionele ontwikkelaars, gezamenlijk kunnen bijdragen aan de te bouwen toepassing.
Zie de volgende artikelen waarin verschillende items worden besproken die aan het begin van elke toepassingsontwikkeling moeten worden overwogen: