Del via


Versionsstyring med løsningsfiler

Værktøjet SolutionPackager kan bruges sammen med et versionsstyringssystem. Når en .zip-løsningsfil er pakket ud til en mappe, skal du blot tilføje og sende filerne til dit versionsstyringssystem. Disse filer kan derefter synkroniseres på en anden computer, hvor de kan pakkes i en ny identiske .zip-løsningsfil.

Et vigtigt aspekt, når du bruger udpakkede komponentfiler i kildekontrol, er at tilføjelse af alle filer i versionsstyringen kan forårsage unødig gentagelse. I Filreference for løsningskomponent kan du se, hvilke filer der genereres for den enkelte komponenttype, og hvilke filer der anbefales til brug i versionsstyring.

Da yderligere tilpasninger og ændringer er nødvendige for løsningen, skal udviklere redigere eller tilpasse komponenter gennem eksisterende midler, eksportere igen for at oprette en .zip-fil og pakke den komprimerede løsningsfil ud i samme mappe.

Vigtigt

Med undtagelse af de sektioner, der er beskrevet i Hvornår tilpasningsfilen skal redigeres, understøttes manuel redigering af udpakkede komponentfiler og. zip-filer ikke.

Når værktøjet SolutionPackager udpakker komponentfilerne, vil det ikke overskrive de eksisterende komponentfiler med samme navn, hvis filindholdet er identiske. Værktøjet bruger desuden den skrivebeskyttede attribut på komponentfiler, der producerer en advarsel i konsolvinduet om, at bestemte filer ikke er skrevet. Dette gør det muligt for brugeren at udtjekke, fra versionsstyring, det minnimale sæt af filer, der ændres. /clobber-parameteren kan bruges til at tilsidesætte og forårsage, at skrivebeskyttede filer skrives eller slettes. /allowWrite-parameteren kan bruges til at vurdere, hvilken indvirkning en udpakning har uden faktisk at få filer skrevet eller slettet. Brug af /allowWrite-parameteren med detaljeret logføring er effektiv.

Efter udpakning er afsluttet med det minimale sæt filer tjekket ud fra versionsstyring, kan en udvikler sende de ændrede filer tilbage til versionsstyring, som det er udført med en enhver anden type af kildefil.

Teamudvikling

Når flere udviklere arbejder på samme løsningskomponenten, kan en konflikt opstå, hvor ændringer fra to udviklere medfører ændringer i en enkelt fil. Denne forekomst er minimeret ved opsplitning af hver individuelt redigerbare komponent eller underkomponent i en særskilt fil. Overvej følgende eksempel.

  1. Udvikler A og B arbejder begge på den samme løsning.

  2. På uafhængige computere får de begge de nyeste versioner til løsningen fra versionsstyring og pakken og importerer en ikke-administreret .zip-løsningsfil til uafhængige Microsoft Dataverse-organisationer.

  3. Udvikler A tilpasser systemvisningen "Aktive kontaktpersoner" og den primære formular for objektet Kontaktperson.

  4. Udvikler B tilpasser den primære formular for objektet Konto og ændrer "Visning for kontaktpersonopslag".

  5. Begge udviklere eksporterer en ikke-administreret .zip-løsningsfil og pakker ud.

    1. Udvikler A skal tjekke én fil ud til den primære kontaktformular og én fil for visningen "Aktive kontaktpersoner".

    2. Udvikler B skal tjekke én fil ud til den primære kontoformular og én fil for "Visning for kontaktpersonopslag".

  6. Begge udviklere kan sende data, i vilkårlig rækkefølge, da deres respektive ændringer berører separate filer.

  7. Når begge afsendelser er fuldført, kan de gentage trin 2 og derefter fortsætte med at foretage yderligere ændringer i deres uafhængige organisationer. De har hver især begge sæt ændringer, uden overskrivninger af deres eget arbejde.

Det foregående eksempel fungerer kun, når der sker ændringer i separate filer. Det er uundgåeligt, at uafhængige tilpasninger kræver ændringer i en enkelt fil. Baseret på ovenstående eksempel skal du tænke på, at udvikler B har tilpasset visningen "Aktive kontaktpersoner", mens udvikler A også har tilpasset den. Rækkefølgen af hændelser er vigtig i dette nye eksempel. Den korrekte proces for at afstemme denne situation, er som følger skevet helt ud.

  1. Udvikler A og B arbejder begge på den samme løsning.

  2. På uafhængige computere får de begge de nyeste versioner til løsningen fra versionsstyring og pakken og importerer en ikke-administreret .zip-løsningsfil til uafhængige organisationer.

  3. Udvikler A tilpasser systemvisningen "Aktive kontaktpersoner" og den primære formular for objektet Kontaktperson.

  4. Udvikler B tilpasser den primære formular for objektet Konto og ændrer "Aktive kontaktpersoner".

  5. Begge udviklere eksporterer en ikke-administreret løsning. .zip-fil og udpakning.

    1. Udvikler A skal tjekke én fil ud til den primære kontaktformular og én fil for visningen "Aktive kontaktpersoner".

    2. Udvikler B skal tjekke én fil ud til den primære kontoformular og én fil for "Aktive kontaktpersonet".

  6. Udvikler A er først klar.

    1. Før Udvikler A overfører til kildekontrol, skal de have de seneste kilder for at sikre, at ingen forudgående indtjekninger er i konflikt med deres ændringer.

    2. Der er ingen konflikter, så Udvikler A kan sende.

  7. Udvikler B er klar efter udvikler A.

    1. Før Udvikler B overfører skal de have de nyeste kilder for at sikre, at ingen forudgående indtjekninger er i konflikt med deres ændringer.

    2. Der er en konflikt, fordi filen for "Aktive kontaktpersoner" er blevet ændret, siden Udvikler B sidst har hentet de nyeste kilder.

    3. Udvikler B skal afstemme konflikten. Det er muligt, at funktionerne i versionsstyringssystemet kan hjælpe denne proces. Ellers er følgende valgmuligheder alle levedygtige.

      1. Udvikler B kan gennem en eventuel versionsstyringsoversigt se, at udvikler A har foretaget den forudgående ændring. De kan diskutere hver ændring gennem direkte kommunikation. Derefter skal Udvikler B bare opdatere organisationen med den aftalte løsning. Udvikler B eksporterer, udpakker og overskriver derefter filerne i konflikten og sender.

      2. Tillad versionsstyring at overskrive den lokale fil. Udvikler B pakker løsningen og importerer den til deres organisation, og derefter vurderer han tilstanden af visningen og tilpasser den igen efter behov. Udvikler B kan derefter eksportere, udpakke og overskrive filen i konflikt.

      3. Hvis den sidste ændring kan anses for unødvendig, vil Udvikler B tillade, at deres kopi af filen overskriver versionen i versionsstyringen, og sender den.

Uanset om du arbejder på en fælles organisation eller uafhængige organisationer, kræver teamudvikling af Dataverse-løsninger, at personer, der arbejder aktivt på en fælles løsning, er opmærksom på andres arbejde. Værktøjet SolutionPackager eliminerer ikke fuldt ud dette behov, men det giver mulighed for nem fletning af ikke-uoverensstemmende ændringer på niveauet for versionsstyring og fremhæver proaktivt de præcise komponenter, hvor der er opstået konflikter.

De næste afsnit omhandler generelle processer for effektiv brug af værktøjet SolutionPackager til versionsstyring, når der udvikles med teams. Disse virker ligeledes med uafhængige organisationer eller fælles udviklingsorganisationer, men med fælles organisationer vil eksport og udpakning naturligt omfatte alle ændringer, der findes i løsningen, og ikke kun dem, der er foretaget af udvikleren, der udfører eksporten. Når du importerer en .zip-løsningsfil, vil overskrivning af alle komponenter tilsvarende forekomme.

Oprette en løsning

Følgende identificerer de typiske trin, der bruges, når du første gang opretter en løsning.

  1. I en ny organisation kan du oprette en løsning på Dataverse-serveren og derefter tilføje eller oprette komponenter efter behov.

  2. Benyt følgende fremgangsmåde, når du er klar til at tjekke ind.

    1. Eksportér den ikke-administrerede løsning.

    2. Brug værktøjet SolutionPackager til at pakke den eksporterede løsning ud til komponentfiler.

    3. Tilføj de nødvendige filer fra de udpakkede komponentfiler i versionsstyring.

    4. Send disse ændringer til versionsstyring.

Redigere en løsning

Følgende identificerer de typiske trin, der bruges, når du redigerer en eksisterende løsning.

  1. Synkroniser eller hent de nyeste filkilder til løsningskomponenten.

  2. Brug værktøjet SolutionPackager til at pakke komponentfiler i en ikke-administreret .zip-løsningsfil.

  3. Importér den ikke-administrerede løsningsfil til en organisation.

  4. Tilpas og rediger løsningen efter behov.

  5. Benyt følgende fremgangsmåde, når du er klar til at tjekke ændringerne ind i versionsstyring.

    1. Eksportér den ikke-administrerede løsning.

    2. Brug værktøjet SolutionPackager til at pakke den eksporterede løsning ud til komponentfiler.

    3. Synkroniser eller hent de nyeste kilder fra versionsstyring.

    4. Afstem eventuelle konflikter.

    5. Send ændringerne til versionsstyring.

    Trin 2 og 3 skal udføres, før yderligere tilpasninger foretages i udviklingsorganisationen. I trin 5 skal trin b udføres før trin c.

Se også

Filreference til løsningskomponent (SolutionPackager)
SolutionPackager-værktøj