Del via

Versionsstyring med løsningsfiler

Løsningspakker-værktøjet kan bruges sammen med et kildestyringssystem. 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. Gå til Filreference for løsningskomponent for at 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 Løsningspakker udtrækker komponentfilerne, vil det ikke overskrive de eksisterende komponentfiler med samme navn, hvis filindholdet er identiske. Værktøjet respekterer desuden den skrivebeskyttede attribut på komponentfiler, hvilket resulterer i en advarsel i konsolvinduet om, at bestemte filer ikke blev skrevet. Denne beskyttelse gør det muligt for brugeren at tjekke ud, fra versionsstyring, det minimale 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.

Filformater for kildekontrol

Løsningspakkeværktøjet understøtter to filformater for udpakkede komponentfiler. Hvis du vælger det rigtige format på forhånd, behøver du ikke at overføre lagerstrukturen senere.

XML-format (ældre) YAML-kildekontrolformat
Løsningsmanifest Other\Solution.xml + Other\Customizations.xml solutions/<name>/solution.yml og understøttende YAML-filer
Læsbarhed Detaljeret XML Kompakt YAML – nemmere at læse og gennemse
Diff-kvalitet i Git Store XML-forskelle Minimale, fokuserede ændringer
Lager med flere løsninger Ikke understøttet Understøttet – flere løsninger deler én mappe
Lærredsapps (.msapp) Ikke understøttet Understøttet
Moderne flows Ikke understøttet Understøttet
Oprindelig Git-integration Bruges ikke Bruges altid – Git-integration skriver altid YAML

Hvornår skal YAML-formatet bruges: Til alle nye projekter, og når du bruger oprindelig Dataverse Git-integration. YAML-formatet er fremadkompatibelt og giver en renere ændringshistorik.

Hvornår skal du bruge XML-formatet: Kun når du arbejder med eksisterende lagre, der allerede bruger XML-formatet, eller når du bruger ældre værktøjer, der ikke understøtter YAML.

Bemærkning

Når du sender løsninger ved hjælp af den oprindelige Git-integration i Power Apps, gemmes de altid i YAML-versionsstyringsformatet. Hvis du vil pakke denne kilde manuelt ved hjælp af SolutionPackager eller pac solution pack, skal mappen følge YAML-mappestrukturen. Flere oplysninger: SolutionPackager-værktøj – Filformater til kildekontrol

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 kilder til løsningen fra versionsstyring, pakke og importerer en ikke-administreret løsning .zip fil til uafhængige Microsoft Dataverse organisationer.

  3. Developer A tilpasser systemvisningen "Aktive kontakter" og hovedformularen for objektet Kontakt.

  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 for hovedformularen Kontakt og én fil til visningen "Aktive kontakter".

    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. På baggrund af det eksempel, der blev vist tidligere, skal du overveje, at udvikler B har tilpasset visningen "Aktive kontakter", mens udvikler A også tilpassede 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 beskrevet 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. Developer A tilpasser systemvisningen "Aktive kontakter" og hovedformularen for tabellen Kontakt.

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

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

    1. Udvikler A skal tjekke én fil ud for hovedformularen Kontakt og én fil til visningen "Aktive kontakter".

    2. Udvikler B skal tjekke én fil ud for hovedformularen Konto og én fil til visningen "Aktive kontakter".

  6. Udvikler A er først klar.

    1. Før udvikler A overfører til kildekontrol, skal vedkommende hente den nyeste kildekode for at sikre, at ingen forudgående indtjekninger er i konflikt med vedkommendes æ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 kontakter" er blevet ændret, siden udvikler B sidst hentede 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 kildekontrol at overskrive den lokale fil. Udvikler B pakker løsningen og importerer den til sin 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 hans kopi af filen overskriver versionen i versionsstyringen, og sender den.

Uanset om du arbejder på et fælles miljø eller uafhængigt miljø, 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 Løsningpakker 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 Løsningpakker til versionsstyring, når der udvikles med teams. Disse virker ligeledes med uafhængige miljøer eller fælles udviklingsmiljøer, men med fælles miljøer 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.

Opret en løsning

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

  1. I et nyt miljø med Dataverse kan du oprette en løsning 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 Løsningpakker 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 Løsningspakker til at pakke komponentfiler i en ikke-administreret .zip-løsningsfil.

  3. Importér den ikke-administrerede løsningsfil til et miljø.

  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 Løsningspakker 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)
Løsningspakkeværktøj
Kildestyringsfilformater

  • Last updated on