Een gezond ALM voor modelgestuurde app-formulieren onderhouden
Dit artikel biedt u informatie over de verschillende scenario's voor het implementeren en beoefenen van gezond Application Lifecycle Management (ALM) voor het aanpassen van formulieren in uw modelgestuurde app-oplossingen.
In de volgende secties wordt beschreven hoe het samenvoegen van formulieren werkt en hoe u aanpassingen kunt onderhouden. De basisontwikkelingsscenario's met aanbevelingen voor het onderhouden van een geslaagd ALM voor een modelgestuurd app-formulier worden in detail besproken in de volgende secties. Elk scenario omvat stappen om een goed ALM-proces te implementeren bij het bijwerken van uw oplossing of modelgestuurde app.
Volg deze stappen om een gezond formulier-ALM te implementeren voor dit scenario.
- Maak een nieuw formulier met de naam FormA in uw ontwikkelomgeving en voer aanpassingen uit op het formulier.
- Maak een nieuwe oplossing (met de naam Oplossing A in het onderstaande diagram) in de ontwikkelomgeving (een onbeheerde oplossing) en voeg uw nieuwe formulier toe. Exporteer de oplossing als beheerd. Met deze stap exporteert u een volledige FormXml voor het formulier.
- Importeer de beheerde oplossing uit stap 2, waarmee FormA in de testomgeving wordt gemaakt, in uw testomgeving. In het onderstaande diagram wordt FormA gemaakt in de testomgeving en de gebruikersinterface voor het formulier toont Field1 en Field2 die door Oplossing A zijn toegevoegd aan het formulier.
- Wanneer u het formulier dat u in stap 1 hebt gemaakt, verder aanpast met een nieuwe ontwikkelomgeving (bron), importeert u de beheerde Oplossing A die u in stap 2 hebt gemaakt en moet u ervoor zorgen dat in het ontwikkelexemplaar dat u gebruikt FormA een beheerde status heeft. Zoals wordt weergegeven in het onderstaande diagram, wordt de beheerde Oplossing A geïmporteerd in de ontwikkelomgeving en het formulier wordt aangepast, waardoor actieve aanpassingen worden gemaakt. Vervolgens kan FormA worden toegevoegd aan een nieuwe onbeheerde oplossing (Oplossing B in het diagram) en geëxporteerd als een beheerde oplossing uit de ontwikkelomgeving. Met deze stap exporteert u een differentiële FormXml voor het formulier.
- Importeer de beheerde oplossing (Oplossing B) uit stap 4 in uw testomgeving. Zoals wordt weergegeven in het onderstaande diagram voegt Oplossing B een nieuw Field3 toe aan FormA en wordt Field2, dat was toegevoegd door Oplossing A, verwijderd. De gebruikersinterface voor het formulier in de testomgeving toont nu Field3 en Field1 in het formulier, maar niet Field2 na de samenvoeging.
Zoals u ziet in het onderstaande diagram is het geen gezonde ALM-praktijk om meerdere beheerde oplossingen te maken vanuit de ontwikkelomgeving waar de basisoplossing (Oplossing A) een onbeheerde status heeft. Wanneer u een andere onbeheerde oplossing maakt (Oplossing B) voor het onbeheerde formulier, wordt de FormXml namelijk geëxporteerd als een volledige FormXml in plaats van een differentiële FormXml, zoals weergegeven in het geldige scenario hierboven. Wijzigingen zoals het verwijderen van een kolom worden vervolgens niet toegepast.
Volg deze stappen om een gezond formulier-ALM te implementeren voor dit scenario.
Maak een nieuw formulier met de naam FormA in uw ontwikkelomgeving en voer aanpassingen uit op het formulier.
Maak een oplossing (Oplossing A in het onderstaande diagram, een onbeheerde oplossing) en voeg uw nieuwe formulier toe. Exporteer de oplossing als beheerd. Met deze stap exporteert u een volledige FormXml voor het formulier.
Importeer de beheerde oplossing uit stap 2, om zo het formulier te maken in de testomgeving. In het onderstaande diagram wordt FormA gemaakt in de testomgeving en de gebruikersinterface voor het formulier toont Field1 en Field2 die door Oplossing A zijn toegevoegd aan het formulier.
Wanneer u het formulier dat u in stap 1 hebt gemaakt verder aanpast met patches, gebruikt u dezelfde omgeving waarin Oplossing A een onbeheerde status heeft en maakt u een patch voor de oplossing en past u het formulier aan. Exporteer de patch vervolgens als een beheerde oplossing. Met deze stap exporteert u een volledige FormXml voor het formulier.
Importeer de beheerde patchoplossing uit stap 4 in uw testomgeving. Zoals weergegeven in het onderstaande diagram wordt met de patch Oplossing A een nieuw Field3 toegevoegd aan FormA en wordt Field2, dat was toegevoegd door Oplossing A, verwijderd.
Notitie
Patches met volledige formXml worden altijd vergeleken met de basislaag op basis waarvan de patch is gemaakt en negeren eventuele tussenliggende patches tussen de basis en de huidige patch. Als gevolg wordt Field2 verwijderd omdat het in de basislaag Oplossing A bestaat en de verwijdering wordt gedetecteerd. Anderzijds wordt Field3 toegevoegd door deze patchoplossing en kan deze niet worden verwijderd door volgende patches. Velden die via patchoplossingen worden toegevoegd, zijn dus additief van aard.
Wanneer u het formulier dat u in stap 1 hebt gemaakt verder aanpast met upgrades, gebruikt u dezelfde omgeving waarin Oplossing A een onbeheerde status heeft en kloont u Oplossing A om de upgradeoplossing te maken en het formulier aan te passen. Exporteer de upgrade Oplossing A als een beheerde oplossing. Met deze stap exporteert u een volledige FormXml voor het formulier.
Importeer de beheerde upgrade (Oplossing A) uit stap 6 in uw testomgeving. Zoals wordt weergegeven in het onderstaande diagram voegt de upgrade Oplossing A een nieuw Field4 toe aan FormA en wordt Field2, dat was toegevoegd door Oplossing A, verwijderd. De gebruikersinterface voor het formulier in de testomgeving toont nu Field1, Field3 en Field4 in het formulier, maar Field2 wordt verwijderd nadat het formulier is samengevoegd.
Volg deze stappen om een gezond formulier-ALM te implementeren voor dit scenario.
- Bewerk een bestaand beheerd formulier, genaamd FormB in dit voorbeeld, in uw ontwikkelomgeving en voer aanpassingen uit op het formulier. Oplossing A is de beheerde oplossing die al is geïnstalleerd voor het formulier in de ontwikkelomgeving.
- Maak een nieuwe oplossing (Oplossing B in het onderstaande diagram, een onbeheerde oplossing) en voeg FormB toe. Exporteer de oplossing als beheerd. Met deze stap exporteert u een differentiële FormXml voor het formulier.
- Importeer de beheerde oplossing uit stap 2, om zo een tweede laag voor het formulier te maken. In het onderstaande diagram krijgt FormB de samengevoegde wijzigingen van Oplossing A en Oplossing B in de testomgeving en de gebruikersinterface voor het formulier toont nu Field1 en Field3 in het formulier, maar niet Field2, dat is verwijderd door Oplossing B.
- Wanneer u het formulier dat u in stap 1 hebt aangepast, verder aanpast met nieuwe beheerde oplossingen, moet u ervoor zorgen dat u een nieuwe ontwikkelomgeving gebruikt met FormB in een beheerde status. Zoals wordt weergegeven in het onderstaande diagram, worden de beheerde oplossingen Oplossing A en Oplossing B geïmporteerd in de nieuwe ontwikkelomgeving. FormB wordt aangepast door actieve aanpassingen te maken, die vervolgens kunnen worden toegevoegd aan een nieuwe oplossing (Oplossing C in het diagram) en geëxporteerd als beheerde oplossing.
- Importeer de beheerde Oplossing C uit stap 4 in uw testomgeving. Zoals wordt weergegeven in het onderstaande diagram voegt Oplossing C een nieuw Field4 toe aan FormB en wordt Field3, dat was toegevoegd door Oplossing B, verwijderd. De gebruikersinterface voor het formulier in de testomgeving toont nu Field1 en Field4 in het formulier, maar niet Field2 en Field3.
Zoals u ziet in het onderstaande diagram is het geen gezonde ALM-praktijk om meerdere beheerde oplossingen te maken vanuit de ontwikkelomgeving die nog een onbeheerde oplossing bevat die u voor hetzelfde formulier hebt gemaakt. Oplossing B heeft een onbeheerde status. Wanneer u nog een onbeheerde oplossing (Oplossing C) maakt voor FormB, wordt de FormXml geëxporteerd als een differentiële FormXml, zoals getoond in stap 4 in het bovenstaande scenario. FormB bevat echter ook de wijzigingen uit Oplossing B, die worden overschreven door uw nieuwe wijzigingen.
Zoals te zien is in het onderstaande diagram, is Field3 toegevoegd aan FormB in Oplossing B. Maar als u nu een nieuwe Oplossing C maakt in deze omgeving, met Oplossing B met een onbeheerde status, en Field3 verwijdert, wordt Field3 ook verwijderd in de ontwikkelomgeving. Veld3 wordt niet bijgehouden in de diff FormXml wanneer de oplossing wordt geëxporteerd, omdat de wijziging van het toevoegen en verwijderen van deze kolom is gemaakt in dezelfde actieve laag. Dus wanneer beheerde Oplossing C wordt geïmporteerd in de testomgeving, bevat het formulier nog steeds Field3 omdat de differentiële FormXml het nooit als verwijderd registreert (zoals het werd verwijderd in stap 5 in het gezonde ALM-scenario hierboven). Als u uw formulieraanpassingen op deze manier uitvoert, wordt de ontwikkelomgeving inconsistent met de testomgeving.
Volg deze stappen om een gezond formulier-ALM te implementeren voor dit scenario.
Pas een bestaand beheerd formulier, genaamd FormB in dit voorbeeld, in uw ontwikkelomgeving aan en voer aanpassingen uit op het formulier. Oplossing A is de beheerde oplossing die al is geïnstalleerd voor het formulier in de ontwikkelomgeving.
Maak een oplossing (Oplossing B, een onbeheerde oplossing) en voeg FormB toe. Exporteer de oplossing als beheerd. Met deze stap exporteert u een differentiële FormXml voor het formulier.
Importeer de beheerde Oplossing B uit stap 2, om zo een tweede laag voor het formulier te maken. In het onderstaande schema krijgt FormB de samengevoegde wijzigingen van Oplossing A en Oplossing B in de testomgeving. Bovendien worden in de gebruikersinterface voor FormB wel Field1 en Field3 in het formulier weergegeven, maar niet Field2, dat is verwijderd door Oplossing B.
Wanneer u het formulier dat u in stap 1 hebt aangepast nog verder aanpast met een patchoplossing, kunt u dezelfde ontwikkelomgeving gebruiken als in stap 1 waar Oplossing B bestaat met een onbeheerde status. Zoals weergegeven in het onderstaande diagram heeft Oplossing A een beheerde status en heeft Oplossing B een onbeheerde status. Het formulier wordt verder aangepast en u maakt een patch voor Oplossing B om uw formulier aan deze oplossing toe te voegen en deze te exporteren als een beheerde patchoplossing. Met deze stap exporteert u een differentiële FormXml.
Importeer de beheerde patch Oplossing B uit stap 4 in uw testomgeving. Zoals weergegeven in het onderstaande diagram wordt met de patch Oplossing B een nieuw Field4 toegevoegd aan FormA en wordt Field3, dat was toegevoegd door Oplossing B, verwijderd.
Notitie
Patches zijn additief van aard en kunnen geen onderdelen, zoals kolommen, uit het formulier verwijderen. Dus, Field3 wordt niet uit het formulier verwijderd. De gebruikersinterface voor het formulier in de testomgeving bevat nu Field1, Field3 en Field4 in het formulier, maar niet Field2.
Wanneer u het formulier dat u in stap 1 hebt gemaakt verder aanpast met upgrades, gebruikt u dezelfde omgeving waarin Oplossing A een onbeheerde status heeft en kloont u Oplossing B om de upgradeoplossing te maken en FormB aan te passen. Exporteer de upgrade als een beheerde oplossing. Met deze stap exporteert u een differentiële FormXml voor het formulier.
Importeer de beheerde upgradeoplossing Oplossing B uit stap 6 in uw testomgeving. Zoals wordt weergegeven in het onderstaande diagram voegt Upgrade voor oplossing B een nieuw Field5 toe aan FormB en wordt Field3, dat was toegevoegd door Oplossing B, verwijderd. De gebruikersinterface voor het formulier in de testomgeving toont nu Field1, Field4 en Field5 in het formulier, maar Field2 en Field3 zijn verwijderd.
Onbeheerde oplossingen en aanpassingen voor een nieuw formulier in meerdere ontwikkelomgevingen onderhouden
Volg deze stappen om een gezond formulier-ALM te implementeren voor dit scenario.
- Maak in Ontwikkelingsomgeving 1 een nieuw FormA en voer aanpassingen uit op het formulier.
- Maak een oplossing (Oplossing A in het onderstaande diagram, een onbeheerde oplossing) en voeg uw nieuwe formulier toe. Exporteer de oplossing als onbeheerd. Met deze stap exporteert u een volledige FormXml voor het formulier.
- In Ontwikkelingsomgeving 2 importeert u de onbeheerde oplossing uit stap 2, waarmee het formulier in Ontwikkelingsomgeving 2 wordt gemaakt. In het onderstaande diagram wordt FormA gemaakt en de gebruikersinterface voor het formulier toont Field1 en Field2 die door Oplossing A zijn toegevoegd aan het formulier.
- U past het formulier verder aan in Ontwikkelomgeving 2 door actieve aanpassingen in de omgeving door te voeren, zoals het toevoegen van een nieuwe kolom met de naam Field3. FormulierA toont nu Veld1, Veld2 en Veld3.
- In uw Ontwikkelomgeving 1 past u het formulier ook verder aan door Field4 toe te voegen. De gebruikersinterface voor het formulier in Ontwikkelomgeving 1 bevat nu Field1, Field2 en Field4.
- Exporteer de onbeheerde Oplossing A met de wijzigingen die u in stap 5 hebt doorgevoerd. Met deze stap exporteert u een volledige FormXml voor het formulier.
- Importeer in Ontwikkelomgeving 2 de onbeheerde Upgrade van Oplossing A uit stap 6. Aangezien de oplossing die u importeert de volledige FormXml bevat voor FormA, wordt de actieve aanpassing gemaakt in Ontwikkelomgeving 1 overschreven. Het formulier toont nu dus alleen Field1, Field2 en Field4, maar niet Field3, de extra actieve aanpassing die is uitgevoerd in Ontwikkelomgeving 1. Dit probleem treedt op bij elke import van een onbeheerde oplossing met de volledige FormXml voor het formulier.
Onbeheerde oplossingen en aanpassingen voor een bestaand formulier in meerdere ontwikkelomgevingen onderhouden
Volg deze stappen om een gezond formulier-ALM te implementeren voor dit scenario.
- Pas in Ontwikkelomgeving 1 een bestaand formulier, genaamd FormB in dit voorbeeld, aan. Voer vervolgens aanpassingen op het formulier uit.
- Maak een oplossing (Oplossing B in het onderstaande diagram, een onbeheerde oplossing) en voeg FormB toe. Exporteer de oplossing als onbeheerd. Met deze stap exporteert u een differentiële FormXml voor het formulier.
- Importeer in Ontwkkelomgeving 2 de onbeheerde oplossing uit stap 2, om zo een tweede laag voor het formulier te maken. In de gebruikersinterface van FormB ziet u Field1, Field2 en Field3 na het samenvoegen van de formulieren.
- U past het formulier verder aan in Ontwikkelomgeving 2 door actieve aanpassingen in de omgeving door te voeren, zoals het toevoegen van een nieuwe kolom met de naam Field4. FormulierB toont nu Veld1, Veld2, Veld3 en Veld4.
- In Ontwikkelomgeving 1 past u het formulier ook verder aan door de nieuwe kolom Field5 toe te voegen. De gebruikersinterface voor het formulier in Ontwikkelomgeving 1 bevat nu Field3 en Field5.
- Exporteer de onbeheerde Oplossing B met de wijzigingen die u in stap 5 hebt doorgevoerd. Met deze stap exporteert u een differentiële FormXml voor het formulier.
- Importeer in Ontwikkelomgeving 2 de onbeheerde Upgrade van Oplossing B uit stap 6. Aangezien de oplossing die u importeert de differentiële FormXml bevat voor FormB, wordt deze samengevoegd met de actieve aanpassing gemaakt in Ontwikkelomgeving 1. Het formulier bevat nu Field1, Field2, Field3, Field4 en Field5. Dit probleem treedt op voor elke import van een onbeheerde oplossing met de differentiële FormXml voor het formulier.
- Als het formuliersamenvoeging in stap 7 niet is wat u wilt, ook al importeert u een differentiële FormXml met de onbeheerde oplossing en wilt u de actieve aanpassingen gemaakt in Ontwikkelomgeving 2 kunnen overschrijven, dan moet u de actieve laag voor FormB verwijderen. Meer informatie: Een onbeheerde laag verwijderen.
- Exporteer de onbeheerde Oplossing B met de wijzigingen die u in stap 5 hebt doorgevoerd. Met deze stap exporteert u een differentiële FormXml voor het formulier.
- Importeer in Ontwikkelomgeving 2 de onbeheerde Upgrade van Oplossing B uit stap 9. Aangezien er geen actieve laag is voor het formulier in Ontwikkelomgeving 2 (zie stap 8), worden alle wijzigingen uit de onbeheerde Oplossing B geïmporteerd, ook al importeert u de differentiële FormXml voor FormB. Het formulier bevat nu alleen Field1, Field2, Field3 en Field5. Dit probleem treedt op voor elke import van een onbeheerde oplossing met de differentiële FormXml voor het formulier. Dit is hetzelfde resultaat als stap 7 in het scenario Onbeheerde oplossingen en aanpassingen voor een bestaand formulier in meerdere ontwikkelomgevingen onderhouden.
Elk geëxporteerd oplossingspakket bevat een customizes.xml-bestand. Wanneer een formulier wordt opgenomen in een oplossing, bestaat de bijbehorende formulierdefinitie in de FormXml-secties van het bestand customizes.xml. FormXml kan volledig of differentieel zijn.
De FormXml die u krijgt bij het exporteren van een oplossing voor een formulier met een onbeheerde status, wordt een volledige FormXml genoemd. Volledig betekent dat het de volledige formulierdefinitie bevat. Wanneer u een nieuw formulier maakt en exporteert, is het formulier altijd een volledige FormXml, omdat het formulier in de omgeving waaruit u exporteert een onbeheerde status en maakstatus heeft. Als u nog meer oplossingen uit dezelfde omgeving exporteert, bevatten deze ook een volledige FormXml. Omdat het kenmerk solutionaction
een differentiële FormXml aanduidt, bevat de volledige FormXml in het bestand customization.xml in de oplossing die u exporteert geen solutionaction
-kenmerken.
De FormXml die u krijgt bij het exporteren van een oplossing voor een formulier met een beheerde status, wordt een differentiële FormXml genoemd. Differentieel betekent dat de FormXml alleen de wijzigingen bevat die zijn aangebracht in de actieve aanpassingen in die omgeving en niet de volledige formulierdefinitie. Wanneer u een bestaand beheerd formulier aanpast en exporteert, is het formulier altijd een differentiële FormXml zijn omdat deze alleen de actieve wijzigingen bevat die hierin zijn aangebracht. De differentiële FormXml in het bestand customization.xml in de oplossing die u exporteert, bevat solutionaction
-kernmerken die bepalen wat de veranderingen zijn, zoals Toegevoegd, Verwijderd en Gewijzigd.
De differentiële FormXml zorgt ervoor dat uw oplossing alleen de wijzigingen weergeeft die uw app nodig heeft en minder wordt beïnvloed door wijzigingen van andere lagen. Daarnaast wordt de oplossing minder omvangrijk en kan deze sneller worden geïmporteerd.