Källkontroll med lösningsfiler

Verktyget Solution Packager kan användas med alla källkontrollsystem. När en lösningsfil i zip-format extraheras till en mapp lägger du bara till och skickar filerna till källkontrollsystemet. Dessa filer kan sedan synkroniseras på en annan dator där de kan packas i en ny, identisk lösningsfil i zip-format.

En viktig aspekt när du använder extraherade komponentfiler i källkontroll innebär att om du lägger till alla filer i källkontrollen kan detta leda till onödig duplicering. Gå till Filreferensen för komponenten för att se vilka filer som genereras för respektive komponenttyp, samt vilka filer som rekommenderas för användning i källkontroll.

Eftersom ytterligare anpassningar och ändringar är nödvändiga för lösningen bör utvecklare redigera eller anpassa komponenter på befintliga sätt, exportera på nytt i syfte att skapa en zip-fil och sedan extrahera den komprimerade lösningsfilen till samma mapp.

När Solution Packager-verktyget extraherar komponentfilerna skriver det inte över befintliga komponentfiler med samma namn om filinnehållet är identiskt. Dessutom bevarar verktyget skrivskyddsattributet på komponentfiler och genererar en varning i konsolfönstret om att vissa filer inte skrevs. Detta skydd gör det möjligt för användaren att via källgranskaren checka ut den minimala uppsättning filer som ändras. /clobber-parametern kan användas för att åsidosätta och göra så att skrivskyddade filer skrivs eller tas bort. /allowWrite-parametern kan användas för att bedöma vilken effekt en extraheringsåtgärd har utan att faktiskt orsaka att några filer skrivs eller tas bort. Det är effektivt att använda /allowWrite-parametern med utförlig loggning.

När extraheringsåtgärden har slutförts med den minimala mängd filer som har checkats ut från källkontrollen kan en utvecklare skicka tillbaka de ändrade filerna till källkontrollen, precis som med alla andra typer av källfiler.

Filformat för källkontroll

Verktyget Solution Packager stöder två filformat för extraherade komponentfiler. Om du väljer rätt format i förväg behöver du inte migrera lagringsplatsens struktur senare.

När du ska använda YAML-formatet: För alla nya projekt och när du använder inbyggd Dataverse Git-integrering. YAML-formatet är framåtkompatibelt och ger renare ändringshistorik.

När du ska använda XML-formatet: Endast när du arbetar med befintliga lagringsplatser som redan använder XML-format, eller när du använder äldre verktyg som inte stöder YAML.

Teamutveckling

När flera utvecklare arbetar med samma komponent i en lösning kan det uppstå en konflikt som medför att ändringar från två utvecklare resulterar i ändringar i en enda fil. Denna förekomst minimeras genom att varje individuellt redigerbar komponent eller delkomponent delas upp i en separat fil. Beakta följande exempel.

1. Utvecklare A och B arbetar båda med samma lösning.

2. På oberoende datorer hämtar de båda de senaste källorna till lösningen från källkontroll, packar och importerar en ohanterad lösnings .zip-fil till oberoende organisationer för Microsoft Dataverse.

3. Developer A anpassar systemvyn "Aktiva kontakter" och huvudformuläret för entiteten Kontakt.

4. Utvecklare B anpassar huvudformuläret för entiteten ”Konto” och ändrar ”Vy för kontaktvisning”.

5. Båda utvecklarna exporterar en icke-hanterad lösning .zip-fil och extraherar den.

   1. Utvecklare A måste checka ut en fil för huvudformuläret Kontakt och en fil för vyn "Aktiva kontakter".

   2. Utvecklare B måste checka ut en (1) fil för huvudformuläret för Konto och en (1) fil för vyn ”Kontaktvisningsvy”.

6. Båda utvecklarna kan skicka in i valfri ordning, detta eftersom deras respektive ändringar berört separata filer.

7. När båda inlämningar har slutförts kan de upprepa steg #2 och sedan fortsätta med att göra ytterligare ändringar i sina egna organisationer. Var och en av dem har båda uppsättningarna av ändringar, utan att skriva över sitt eget arbete.

Det tidigare exemplet fungerar endast när det finns ändringar i separata filer. Det är oundvikligt att oberoende anpassningar kräver ändringar inom en enskild fil. Baserat på exemplet som visades tidigare bör du tänka på att utvecklaren B anpassade vyn "Aktiva kontakter" medan utvecklaren A också anpassade den. I detta nya exempel blir händelseordningen viktig. Den korrekta processen för att stämma av problemet beskrivs här (i sin helhet).

1. Utvecklare A och B arbetar båda med samma lösning.

2. På enskilda datorer hämtar de båda den senaste källkoden för lösningar från källkontrollen, paketerar och importerar en icke-hanterad lösning i zip-format till enskilda organisationer.

3. Developer A anpassar systemvyn "Aktiva kontakter" och huvudformuläret för tabellen Kontakt.

4. Utvecklare B anpassar huvudformuläret för entiteten ”Kontotabell” och ändrar ”Aktiva kontakter”.

5. Båda utvecklarna exporterar en icke-hanterad lösning .zip-fil och extraherar den.

   1. Utvecklare A måste checka ut en fil för huvudformuläret Kontakt och en fil för vyn "Aktiva kontakter".

   2. Utvecklare B måste hämta en fil för huvudformuläret "Konto" och en fil för vyn "Aktiva kontakter".

6. Utvecklare A är redo först.

   1. Innan utvecklare A skickar in till källkontrollen måste han eller hon hämta de senaste källorna för att se till att inga tidigare incheckningar är i konflikt med deras ändringar.

   2. Eftersom det inte finns några konflikter kan utvecklare A lämna in.

7. Utvecklare B är redo näst efter utvecklare A.

   1. Innan utvecklare B skickar in måste de hämta de senaste versionerna av källkoden för att se till att inga tidigare incheckningar är i konflikt med deras ändringar.

   2. Det finns en konflikt eftersom filen för "Aktiva kontakter" har ändrats sedan utvecklaren B senast hämtade de senaste källorna.

   3. Utvecklare B måste lösa konflikten. Det är möjligt att de funktioner i källkontrollsystemet som används kan främja denna process – i annat fall är samtliga följande val möjliga.

      1. Genom historiken för källkontroll (om tillgänglig) kan Utvecklare B se att Utvecklare A har gjort den tidigare ändringen. Via direkt kommunikation kan de diskutera respektive förändring. Utvecklare B behöver sedan endast uppdatera sin organisation med den överenskomna lösningen. Utvecklare B exporterar, extraherar och skriver sedan över den konfliktskapande filen och skickar den.

      2. Tillåt källkontrollen att skriva över den lokala filen. Utvecklare B packar lösningen, importerar den till sin organisation och bedömer sedan vyens tillstånd för att anpassa den vid behov. Därefter kan utvecklare B exportera, extrahera och skriva över filen som är i konflikt.

      3. Om den tidigare ändringen betraktas som onödig tillåter utvecklare B att hans/hennes kopia av filen skriver över versionen i källkontrollen och överför den.

Oavsett om du arbetar med en delad eller fristående miljö kräver teamutveckling av lösningar för Dataverse att de som aktivt arbetar på en gemensam lösning är medvetna om andras arbete. Verktyget SolutionPackager eliminerar inte helt detta behov, men det gör det enkelt att slå samman ändringar som inte är i konflikt på källkontrollnivå, och det framhäver proaktivt de exakta komponenter där konflikter uppstår.

I de kommande avsnitten beskrivs de allmänna processerna för att effektivt använda Solution Packager-verktyget i källkontrollen när man utvecklar i team. Detta fungerar lika väl med oberoende miljöer som med delade utvecklingsmiljöer, men med delade miljöer kommer export och extrahering naturligt att omfatta samtliga befintliga ändringar i lösningen, inte enbart de som utförts av den utvecklare som utför exporten. När du importerar en zip-fil för en lösning kommer på samma sätt det naturliga beteendet att skriva över samtliga komponenter att inträffa.

Skapa en lösning

I denna procedur identifieras de vanligaste stegen när du först skapar en lösning.

1. Skapa en ren miljö med Dataverse, skapa en lösning och lägg sedan till eller skapa komponenter efter behov.

2. Följ dessa steg när du är redo att checka in:

   1. Exportera den icke-hanterade lösningen.

   2. Extrahera lösningen till komponentfiler med hjälp av Solution Packager-verktyget.

   3. Lägg till de filer som behövs i källkontrollen från dessa extraherade komponentfiler.

   4. Skicka in ändringarna till källkontrollen.

Ändra en lösning

I följande procedur identifieras de vanligaste stegen när du modifierar en befintlig lösning.

1. Synkronisera eller hämta de senaste källorna för komponentfiler.

2. Paketera komponentfiler med hjälp av verktyget Solution Packager i en .zip-fil för en icke-hanterad lösning.

3. Importera den oövervakade lösningsfilen i en miljö.

4. Anpassa och redigera lösningen vid behov.

5. Följ dessa steg när du vill kontrollera ändringarna i källkontrollen.

   1. Exportera den icke-hanterade lösningen.

   2. Extrahera den exporterade lösningen till komponentfiler med hjälp av Solution Packager-verktyget.

   3. Synkronisera eller hämta de senaste källorna från källkontrollen.

   4. Lös eventuella konflikter.

   5. Skicka in ändringarna till källkontrollen.

   Steg 2 och 3 måste utföras innan ytterligare anpassningar görs i utvecklingsorganisationen. I steg 5 måste steg b slutföras före steg c.

Se även

Filreferens för lösningskomponenten (SolutionPackager)
SolutionPackager-verktyget
Filformat för källkontroll