Broncodebeheer met oplossingsbestanden

Het hulpmiddel Oplossingspakketten maken kan worden gebruikt met elk broncodebeheersysteem. Nadat een zipbestand van een oplossing in een map is uitgepakt, voegt u de bestanden toe en dient u deze in bij uw versiebeheersysteem. Deze bestanden kunnen vervolgens worden gesynchroniseerd op een andere computer waar zij in een nieuw identiek zipoplossingsbestand kunnen worden ingepakt.

Een belangrijk aspect bij het gebruik van uitgepakte onderdeelbestanden in broncodebeheer, is dat het toevoegen van alle bestanden in het broncodebeheer tot overbodige verdubbeling kan leiden. Ga naar Bestandsverwijzing voor oplossingsonderdelen om te ontdekken welke bestanden voor elk onderdeeltype worden gegenereerd en welke bestanden worden aanbevolen voor gebruik in broncodebeheer.

Aangezien verdere aanpassingen en wijzigingen noodzakelijk zijn voor de oplossing, moeten ontwikkelaars onderdelen bewerken of aanpassen met bestaande middelen, opnieuw exporteren om een zipbestand te maken en het gecomprimeerde oplossingsbestand in dezelfde map uit te pakken.

Wanneer het hulpprogramma Oplossingspakket-maker de onderdeelbestanden extraheert, worden bestaande onderdeelbestanden met dezelfde naam niet overschreven als de inhoud van de bestanden identiek is. Bovendien respecteert het hulpprogramma het alleen-lezen kenmerk van onderdeelbestanden en geeft het een waarschuwing in het consolevenster dat bepaalde bestanden niet zijn geschreven. Door deze beveiliging kan de gebruiker, vanaf broncodebeheer, de minimale reeks bestanden controleren die worden gewijzigd. De parameter /clobber kan worden gebruikt om alleen-lezen bestanden te overschrijven of te verwijderen. De parameter /allowWrite kan worden gebruikt om te bepalen welk effect een uitpakbewerking heeft zonder werkelijk bestanden te schrijven of te verwijderen. Het gebruik van de /allowWrite-parameter met gedetailleerde logboeken is doeltreffend.

Nadat de uitpakbewerking is voltooid met de minimale reeks bestanden die via broncodebeheer zijn gecontroleerd, kan een ontwikkelaar de gewijzigde bestanden opnieuw indienen bij broncodebeheer, zoals gebeurt bij elk ander type bronbestand.

Bestandsindelingen voor broncodebeheer

Het hulpprogramma Solution Packager ondersteunt twee bestandsindelingen voor uitgepakte onderdeelbestanden. Als u vooraf de juiste indeling kiest, hoeft u de structuur van uw opslagplaats niet later te migreren.

Wanneer gebruikt u de YAML-indeling: Voor alle nieuwe projecten en wanneer u systeemeigen Dataverse Git-integratie gebruikt. De YAML-indeling is toekomstgericht compatibel en zorgt voor een duidelijkere wijzigingsgeschiedenis.

Wanneer gebruikt u de XML-indeling: Alleen wanneer u werkt met bestaande opslagplaatsen die al gebruikmaken van de XML-indeling of wanneer u verouderde hulpprogramma's gebruikt die YAML niet ondersteunen.

Teamontwikkeling

Wanneer er meerdere ontwikkelaars zijn die aan hetzelfde oplossingsonderdeel werken, kan zich een conflict voordoen waarbij wijzigingen van twee ontwikkelaars kunnen resulteren in wijzigingen in één bestand. Dit verschijnsel wordt geminimaliseerd door ieder afzonderlijk bewerkbaar onderdeel of subonderdeel op te splitsen in een afzonderlijk bestand. Hier volgt een voorbeeld.

1. Ontwikkelaar A en B werken samen aan dezelfde oplossing.

2. Op aparte computers verkrijgen ze beide de meest recente bronbestanden van de oplossing uit broncodebeheer, verpakken en importeren ze een onbeheerde oplossingen.zip-bestand in aparte Microsoft Dataverse-organisaties.

3. Ontwikkelaar A past de systeemweergave Actieve contactpersonen en het hoofdformulier voor de entiteit Contactpersoon aan.

4. Ontwikkelaar B past het hoofdformulier voor de Account-entiteit aan en wijzigt de "Contactpersoon opzoekweergave".

5. Beide ontwikkelaars exporteren een zipbestand van een onbeheerde oplossing en pakken het uit.

   1. Ontwikkelaar A moet één bestand uitchecken voor het hoofdformulier Contactpersoon en één bestand voor de weergave Actieve contactpersonen.

   2. Ontwikkelaar B moet één bestand controleren voor het hoofdformulier van Account en één bestand voor de "Contact Lookup View".

6. Beide ontwikkelaars kunnen in elke gewenste volgorde hun wijzigingen indienen, aangezien de betreffende wijzigingen afzonderlijke bestanden beïnvloeden.

7. Nadat beide aanpassingen zijn doorgevoerd, kunnen ze stap 2 herhalen en vervolgens wijzigingen blijven aanbrengen aan hun onafhankelijke organisaties. Ze hebben elk beide sets aan wijzigingen zonder hun eigen wijzigingen te overschrijven.

Het vorige voorbeeld werkt alleen als er wijzigingen zijn aan afzonderlijke bestanden. Het is onvermijdelijk dat onafhankelijke aanpassingen wijzigingen vereisen in één bestand. Op basis van het eerder getoonde voorbeeld kunt u overwegen dat ontwikkelaar B de weergave Actieve contactpersonen heeft aangepast terwijl ontwikkelaar A deze ook heeft aangepast. In dit nieuwe voorbeeld wordt de volgorde van de gebeurtenissen belangrijk. Een beschrijving van het juiste proces om deze situatie op te lossen vindt u volledig uitgeschreven hier.

1. Ontwikkelaar A en B werken samen aan dezelfde oplossing.

2. Op onafhankelijke computers krijgen ze allebei de meest recente oplossingsbronnen van bronbeheer en verpakken en importeren ze een zipbestand van een onbeheerde oplossing in onafhankelijke organisaties.

3. Ontwikkelaar A past de systeemweergave "Actieve contactpersonen" en het hoofdformulier voor de tabel "Contact" aan.

4. Ontwikkelaar B past het hoofdformulier voor de tabel Account aan en wijzigt "Actieve contactpersonen".

5. Beide ontwikkelaars exporteren een zipbestand van een onbeheerde oplossing en pakken het uit.

   1. Ontwikkelaar A moet één bestand uitchecken voor het hoofdformulier Contactpersoon en één bestand voor de weergave Actieve contactpersonen.

   2. Ontwikkelaar B moet één bestand uitchecken voor het hoofdformulier Account en één bestand voor de weergave Actieve contactpersonen.

6. Ontwikkelaar A is eerst klaar.

   1. Voordat ontwikkelaar A indient bij versiebeheer, moet die de meest recente broncode ophalen om er zeker van te zijn dat voorgaande check-ins niet in conflict zijn met hun wijzigingen.

   2. Er zijn geen conflicten, dus kan developer A verzenden.

7. Ontwikkelaar B is klaar na ontwikkelaar A.

   1. Voordat ontwikkelaar B verzendt, moet hij of zij de meest recente bronnen ophalen om er zeker van te zijn dat eerdere check-ins niet in conflict zijn met zijn/haar wijzigingen.

   2. Er is een conflict omdat het bestand voor 'Actieve contactpersonen' is gewijzigd sinds ontwikkelaar B de meest recente bronnen heeft opgehaald.

   3. Ontwikkelaar B moet het conflict oplossen. Het is mogelijk dat de functies van het gebruikte broncodebeheersysteem kunnen helpen bij dit proces; anders zijn alle volgende keuzen beschikbaar.

      1. Ontwikkelaar B kan via broncodebeheergeschiedenis, indien beschikbaar, zien dat ontwikkelaar A een eerdere wijziging heeft aangebracht. Via directe communicatie kunnen ze elke wijziging bespreken. Vervolgens moet developer B alleen de organisatie bijwerken met de afgesproken oplossing. Developer B exporteert, extraheert, en overschrijft vervolgens het probleembestand en verzendt dit.

      2. Sta toe dat broncodebeheer het lokale bestand overschrijft. Ontwikkelaar B pakt de oplossing in en importeert deze in zijn/haar organisatie, beoordeelt de status van de weergave en past die indien nodig opnieuw aan. Vervolgens kan ontwikkelaar B het conflicterende bestand exporteren, uitpakken en overschrijven.

      3. Als de eerdere wijziging als overbodig wordt beschouwd, staat ontwikkelaar B toe dat zijn/haar kopie van het bestand de versie overschrijft in broncodebeheer en wordt het bestand verzonden.

Ongeacht of er wordt gewerkt in een gedeelde omgeving of onafhankelijke omgeving, bij teamontwikkeling van Dataverse-oplossingen moeten de mensen die actief meewerken aan een gemeenschappelijke oplossing rekening houden met het werk van anderen. Met het hulpprogramma Oplossingspakketten maken wordt deze noodzaak niet volledig weggenomen, maar niet-conflicterende wijzigingen kunnen eenvoudig worden samengevoegd op niveau van broncodebeheer en de beknopte onderdelen waar zich conflicten voordoen worden proactief gemarkeerd.

De volgende gedeelten zijn de algemene processen om effectief het hulpprogramma Oplossingspakketten maken te gebruiken in broncodebeheer bij het ontwikkelen in teams. Zij werken ook met onafhankelijke omgevingen of gedeelde ontwikkelingsomgevingen, maar met gedeelde omgevingen omvat het exporteren en uitpakken op natuurlijke wijze alle wijzigingen die in de oplossing zijn, en niet alleen de wijzigingen die zijn gemaakt door de ontwikkelaar die het exporteren uitvoert. Evenzo treedt tijdens het importeren van een zipbestand van een oplossing het natuurlijke gedrag op om alle onderdelen te overschrijven.

Een oplossing maken

Deze procedure identificeert de gebruikelijke stappen die worden uitgevoerd wanneer u voor het eerst een oplossing maakt.

1. Maak in een schone omgeving met Dataverse een oplossing en voeg vervolgens indien nodig onderdelen toe of maak deze.

2. Wanneer u klaar bent om in te checken, volg dan deze stappen.

   1. Exporteer de onbeheerde oplossing.

   2. Gebruik het hulpprogramma Oplossingspakketten maken en pak de oplossing uit naar onderdeelbestanden.

   3. Voeg van de uitgepakte onderdeelbestanden, de vereiste bestanden toe aan broncontrole.

   4. Verzend deze wijzigingen naar broncontrole.

Een oplossing wijzigen

De volgende procedure identificeert de gebruikelijke stappen wanneer u een bestaande oplossing wijzigt.

1. Synchroniseer of haal de nieuwste bestandsbronnen van oplossingsonderdelen op.

2. Gebruik het Solution Packager-hulpprogramma om onderdeelbestanden in te pakken in een zipbestand voor een onbeheerde oplossing.

3. Importeer het onbeheerde oplossingsbestand naar een omgeving.

4. Pas de oplossing aan en bewerk de oplossing indien nodig.

5. Wanneer u klaar bent om de wijzigingen in broncodebeheer door te voeren, doet u het volgende.

   1. Exporteer de onbeheerde oplossing.

   2. Gebruik het hulpprogramma Oplossingspakketten maken en pak de geëxporteerde oplossing uit naar onderdeelbestanden.

   3. Synchroniseer of haal de nieuwste bronnen op van broncontrole.

   4. Stem opnieuw af als er zich conflicten voordoen.

   5. Verzend de wijzigingen naar broncontrole.

   Stappen 2 en 3 moeten worden uitgevoerd voordat verdere aanpassingen worden aangebracht in de ontwikkelaarsorganisatie. In stap 5 moet u stap b voor stap c voltooien.

Zie ook

Bestandsverwijzing voor oplossingsonderdelen (SolutionPackager)
SolutionPackager-hulpprogramma
Bestandsindelingen voor broncodebeheer