Share via


Broncodebeheer met oplossingsbestanden

Het hulpmiddel SolutionPackager kan worden gebruikt met elk bronbeheersysteem. Nadat een zipbestand van een oplossing naar een map is uitgepakt, voegt u de bestanden toe aan uw bronbeheersysteem. 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 bronbeheer, is dat het toevoegen van alle bestanden in de broncontrole tot overbodige verdubbeling kan leiden. Zie Bestandsverwijzing voor oplossingsonderdelen als u wilt bekijken welke bestanden voor elk onderdeeltype worden gegenereerd en welke bestanden zijn aanbevolen voor gebruik in broncontrole.

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.

Belangrijk

Behalve voor de secties beschreven in Wanneer u het aanpassingenbestand moet bewerken wordt de handmatige bewerking van uitgepakte componentbestanden en zipbestanden niet ondersteund.

Wanneer het hulpprogramma SolutionPackager de onderdeelbestanden uitpakt, worden bestaande onderdeelbestanden met dezelfde naam niet overschreven als de bestandsinhoud 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. Hierdoor kan de gebruiker vanaf bronbeheer, de minimale reeks bestanden bekijken die worden gewijzigd. De parameter /clobber kan worden gebruikt om alleen-lezen bestanden te negeren en mogelijk 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 met uitgebreide registratie is doeltreffend.

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

Teamontwikkeling

Wanneer er meerdere ontwikkelaars zijn die aan hetzelfde oplossingsonderdeel werken, kan zich een conflict voordoen waarbij wijzigingen van twee ontwikkelaars kan leiden tot wijzigingen in één bestand. Dit exemplaar wordt geminimaliseerd door elk afzonderlijk bewerkbare onderdeel of subonderdeel te ontbinden tot een afzonderlijk bestand. Bekijk het volgende voorbeeld.

  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 voor een onbeheerde oplossing in onafhankelijke Microsoft Dataverse-organisaties.

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

  4. Ontwikkelaar B past het hoofdformulier voor de accountentiteit aan en wijzigt de "Opzoekweergave contactpersoon."

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

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

    2. Ontwikkelaar B moet één bestand controleren voor het hoofdformulier Account, en één bestand voor de weergave "Opzoeken contactpersonen".

  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 wijzigingen, zonder hun eigen werk 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 bovenstaande voorbeeld, moet u zich inbeelden dat ontwikkelaar B de weergave "Actieve contactpersonen" aanpaste terwijl ontwikkelaar A dit ook deed. In dit nieuwe voorbeeld wordt de volgorde van de gebeurtenissen belangrijk. Het juiste proces om deze situatie op te lossen, volledig uitgeschreven, is als volgt.

  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" aan en het hoofdformulier voor de entiteit Contactpersoon.

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

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

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

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

  6. Ontwikkelaar A is eerst klaar.

    1. Voordat developer A verzendt naar broncodebeheer, moet hij of zij de meest recente broncodes ophalen om er zeker van te zijn dat er geen conflicten zijn met eerdere check-ins.

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

  7. Ontwikkelaar B is klaar na ontwikkelaar A.

    1. Voordat developer B verzendt, moet hij of zij de meest recente broncodes ophalen om er zeker van te zijn dat er geen conflicten zijn met eerdere check-in

    2. Er is een conflict omdat het bestand voor "Actieve Contactpersonen" is gewijzigd sinds developer B voor het laatst de meest recente broncodes heeft opgehaald.

    3. Ontwikkelaar B moet het conflict opnieuw ophalen. Het is mogelijk dat de functies van het gebruikte bronbeheersysteem kunnen helpen bij dit proces; anders worden de volgende keuzes allemaal afgesloten.

      1. Ontwikkelaar B kan, via bronbeheergeschiedenis -indien beschikbaar, zien dat de ontwikkelaar A een eerdere wijziging aanbracht. 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. Developer B pakt de oplossing in en importeert deze in zijn of haar organisatie, beoordeelt de status van de weergave en past die opnieuw aan indien nodig. Vervolgens, kan developer B het conflicterende bestand exporteren, uitpakken en overschrijven.

      3. Als de eerdere wijziging als overbodig kan worden beschouwd, staat developer B toe dat zijn of haar kopie van het bestand de versie in broncontrolebeheer overschrijft en verzendt.

Ongeacht of ze werken aan gedeelde organisatie of onafhankelijke organisaties, bij het ontwikkelen van Dataverse oplossingen in team moeten de mensen die actief meerwerken aan een gemeenschappelijke oplossing rekening houden met het werk van anderen. Het hulpprogramma SolutionPackager verwijdert deze behoefte niet volledig, maar maakt eenvoudig samenvoegen van niet-strijdige wijzigingen mogelijk op bronbeheerniveau en benadrukt proactief de beknopte onderdelen waar zich conflicten hebben voorgedaan.

De volgende secties zijn de algemene processen om effectief het hulpprogramma SolutionPackager te gebruiken in bronbeheer bij het ontwikkelen in teams. Zij werken ook met onafhankelijke organisaties of gedeelde ontwikkelingsorganisaties, maar met gedeelde organisaties zal het exporteren en uitpakken alle wijzigingen omvatten die in de oplossing zijn opnemen, en niet alleen deze die zijn gemaakt door de ontwikkelaar die het exporteren uitvoert. Op dezelfde manier zal tijdens het importeren van een zipbestand van een oplossing het natuurlijke gedrag om alle onderdelen te overschrijven, zich voordoen.

Een oplossing maken

De volgende procedure identificeert de gebruikelijke stappen wanneer u voor het eerst een oplossing maakt.

  1. In een overzichtelijke organisatie maakt u een oplossing op de Dataverse server en kunt u indien nodig onderdelen toevoegen of maken.

  2. Wanneer u klaar bent om deze door te voeren, doet u het volgende.

    1. Exporteer de onbeheerde oplossing.

    2. Gebruik het hulpprogramma SolutionPackager 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. Pak de onderdeelbestanden met het hulpprogramma SolutionPackager in een zipbestand voor een onbeheerde oplossing in.

  3. Importeer het onbeheerde oplossingbestand in een organisatie.

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

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

    1. Exporteer de onbeheerde oplossing.

    2. Gebruik het hulpprogramma SolutionPackager 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)
Hulpprogramma SolutionPackager