Källkontroll med lösningsfiler

  • Artikel

Verktyget SolutionPackager kan användas med alla källstyrsystem. När en lösningfil i zip-format har extraherats 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. Se Filreferensen för komponenten för att se vilka filer som har genererats 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.

Viktigt!

Förutom för de avsnitt som beskrivs i När bör anpassningsfilen redigeras stöds inte manuell redigering av extraherade komponentfiler och zip-filer.

När SolutionPackager-verktyget extraherar komponentfilerna kommer det inte att skriva över befintliga komponentfiler med samma namn om filinnehållet är identiskt. Verktyget bevarar även skrivskyddsattributet i komponentfiler som genererar en varning i konsolfönstret om att det inte gick att skriva vissa filer. Detta 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.

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 enskild fil. Denna förekomst minimeras genom att varje individuellt redigerbar komponent eller delkomponent delas upp i en separat fil. Se 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 lösningarna från källkontrollen, paketerar och importerar en icke-hanterad zip-fil till oberoende Microsoft Dataverse-organisationer.

  3. Utvecklare A anpassar systemvyn "Aktiva kontakter" och huvudformuläret för kontaktentiteten.

  4. Utvecklare C anpassar huvudformuläret för entiteten "Konto" och ändrar "Uppslagsvy för kontakt".

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

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

    2. Utvecklare B måste checka ut en fil för huvudformuläret för Konto och en fil för vyn "Uppslagsvy för kontakt".

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

  7. När båda överföringar har slutförts kan de upprepa steg #2 och sedan fortsätta med att göra ytterligare ändringar i sina oberoende organisationer. Båda har båda ändringsuppsättningar, utan att något av deras eget skrivs över.

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. Beroende på vilket exempel som visas ovan bör du tänka på att utvecklare B anpassat vyn "Aktiva kontakter" medan Utvecklare A också anpassade den. I detta nya exempel blir händelseordningen viktig. Den korrekta processen för att korrigera problemet är följande (beskrivet i sin helhet).

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

  2. På oberoende datorer hämtar de båda de senaste lösningarna från källkontrollen, paketerar och importerar en icke-hanterad lösningsfil (zip-format) till oberoende organisationer.

  3. Utvecklare A anpassar systemvyn "Aktiva kontakter" och huvudformuläret för kontaktentiteten.

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

  5. Båda utvecklare exporterar en icke-hanterad lösning. zip-fil och extrahera.

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

    2. Utvecklare B måste checka ut en fil för huvudformuläret för 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 de hämta de senaste källorna för att se till att inga tidigare incheckningar är i konflikt med deras ändringar.

    2. Eftersom inga konflikter finns kan utvecklare A skicka.

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

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

    2. Det finns en konflikt på grund av att filen för "Aktiva kontakter" har ändrats sedan utvecklare 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 organisationen och bedömer sedan läget för vyn och anpassar den efter behov. Därefter kan utvecklare B exportera, extrahera och skriva över filen som är i konflikt.

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

Oavsett om du arbetar med en delad organisation eller fristående organisationer kräver teamutveckling av lösningar för Dataverse att de som aktivt arbetar på en gemensam lösning är medvetna om andras arbete. Detta behov elimineras inte helt och hållet genom SolutionPackager, 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 komponenterna där konflikter har uppstått.

Nästkommande avsnitt utgörs av de allmänna processer som effektivt kan användas för att utnyttja SolutionPackager-verktyget i källkontrollen vid utveckling med hjälp av team. Detta fungerar lika väl med oberoende organisationer som med delade utvecklingsorganisationer, men med delade organisationer kommer export och extrahering naturligt att omfatta samtliga befintliga ändringar i lösningen och 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.

Skapa en lösning

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

  1. Skapa en lösning på servern Dataverse i en ren organisation och lägg sedan till eller skapa komponenter efter behov.

  2. Gör följande 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 SolutionPackager-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 i en zip-fil för icke-hanterad lösning med hjälp av verktyget SolutionPackager.

  3. Importera den icke-hanterade lösningsfilen till en organisation.

  4. Anpassa och redigera lösningen vid behov.

  5. Gör följande 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 SolutionPackager-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 komponent (SolutionPackager)
SolutionPackager-verktyget