Kildekontroll med løsningsfiler

Løsningspakkeverktøyet kan brukes med alle kildekontrollsystemer. Etter at en løsning .zip-fil er pakket ut i en mappe, legger du til og sender filene til kildekontrollsystemet. Disse filene kan deretter synkroniseres på en annen datamaskin der de kan pakkes inn i en ny identisk løsning .zip-fil.

Et viktig aspekt når du bruker utpakkede komponentfiler i kildekontrollen, er at det å legge til alle filene i kildekontrollen kan føre til unødvendig duplisering. Gå til Filreferanse for løsningskomponent for å se hvilke filer som genereres for hver komponenttype, og hvilke filer som anbefales for bruk i kildekontroll.

Etter hvert som flere tilpassinger og endringer er nødvendig for løsningen, bør utviklerne redigere eller tilpasse komponenter ved hjelp av eksisterende metoder, eksportere på nytt for å opprette en zip-fil og pakke ut den komprimerte løsningsfilen i samme mappe.

Når løsningspakkeverktøyet pakker ut komponentfilene, vil det ikke overskrive eksisterende komponentfiler med samme navn hvis filinnholdet er identisk. I tillegg godtar verktøyet skrivebeskyttet-attributtet på komponentfiler, som gir en advarsel i konsollvinduet om at bestemte filer ikke ble skrevet. Denne beskyttelsen gjør det mulig for brukeren å sjekke ut fra kildekontrollen det minste settet med filer som endres. /clobber-parameteren kan brukes til å overstyre og forårsake at skrivebeskyttede filer blir skrevet eller slettet. /allowWrite-parameteren kan brukes til å vurdere hva som påvirker en utpakkingsoperasjon, uten faktisk å forårsake at filer blir skrevet eller slettet. Bruk av /allowWrite-parameteren med utførlig logging er gyldig.

Når utpakkingsoperasjonen er fullført med det minimale settet med filer sjekket ut fra kildekontrollen, kan en utvikler sende de endrede filene tilbake til kildekontrollen, som gjøres med alle andre typer kildefiler.

Filformater for kildekontroll

Løsningspakkeverktøyet støtter to filformater for utpakkede komponentfiler. Hvis du velger riktig format foran, unngås det å måtte overføre repositoriumstrukturen senere.

Når du skal bruke YAML-formatet: For alle nye prosjekter, og når du bruker opprinnelig Datavers Git-integrasjon. YAML-formatet er fremoverkompatibelt og produserer renere endringshistorikk.

Når du skal bruke XML-formatet: Bare når du arbeider med eksisterende repositorier som allerede bruker XML-formatet, eller når du bruker eldre verktøy som ikke støtter YAML.

Teamutvikling

Når det er flere utviklere som arbeider med samme løsningskomponent, kan det oppstå en konflikt der endringer fra to utviklere fører til endringer i én enkelt fil. Denne forekomsten minimeres ved å skrive ut hver enkelt redigerbar komponent eller delkomponent til en separat fil. Vurder følgende eksempel.

1. Utvikler A og B arbeider begge med samme løsning.

2. På uavhengige datamaskiner får de begge de nyeste kildene til løsningen fra kildekontroll, pakke og importere en uadministrert løsning .zip fil til uavhengige Microsoft Dataverse organisasjoner.

3. Utvikler A tilpasser systemvisningen Aktive kontakter og hovedskjemaet for kontaktenheten.

4. Utvikler B tilpasser hovedskjemaet for Forretningsforbindelser-enheten og endrer "Kontaktoppslagsvisning".

5. Begge utviklerne eksporterer en uadministrert løsning .zip-fil og pakker ut.

   1. Utvikler A må sjekke ut én fil for hovedskjemaet Kontakt og én fil for visningen Aktive kontakter.

   2. Utvikler B må sjekke ut én fil for hovedskjemaet for forretningsforbindelse, og én fil for "Kontaktoppslagsvisning".

6. Begge utviklerne kan sende inn, i hvilken som helst rekkefølge, siden de respektive endringene berørte separate filer.

7. Når begge innsendinger er fullført, kan de gjenta trinn 2 og deretter fortsette å gjøre flere endringer i de uavhengige organisasjonene. De har hver sine sett med endringer, uten overskriving av eget arbeid.

Det forrige eksemplet fungerer bare når det er endringer i separate filer. Det er uunngåelig at uavhengige tilpassinger krever endringer i én enkelt fil. Basert på eksemplet som ble vist tidligere, bør du vurdere at utvikler B tilpasset visningen «Aktive kontakter», mens utvikler A også tilpasset den. I dette nye eksemplet blir hendelsesrekkefølgen viktig. Riktig prosess for å løse dette problemet, skrevet fullt ut, beskrives her.

1. Utvikler A og B arbeider begge med samme løsning.

2. På uavhengige datamaskiner får begge de nyeste kildene i løsningen fra kildekontroll, og kan pakke og importere en uadministrert løsning zip-fil til uavhengige organisasjoner.

3. Utvikler A tilpasser systemvisningen Aktive kontakter og hovedskjemaet for kontakttabellen.

4. Utvikler B tilpasser hovedskjemaet for Forretningsforbindelser-tabellen og endrer "Aktive kontakter".

5. Begge utviklerne eksporterer en uadministrert løsning .zip-fil og pakker ut.

   1. Utvikler A må sjekke ut én fil for hovedskjemaet Kontakt og én fil for visningen Aktive kontakter.

   2. Utvikler B må sjekke ut én fil for hovedskjemaet for forretningsforbindelsen og én fil for visningen Aktive kontakter.

6. Utvikler A er klar først.

   1. Før utvikler A sender til kildekontrollen, må de hente de nyeste kildene for å sikre at det ikke er noen tidligere innsjekker i konflikt med endringene.

   2. Det er ingen konflikter, og utvikler A kan derfor sende inn.

7. Utvikler B er klar etter utvikler A.

   1. Før utvikler B sender inn, må de hente de nyeste kildene for å sikre at det ikke er noen tidligere innsjekker i konflikt med endringene.

   2. Det er en konflikt fordi filen for Aktive kontakter har blitt endret siden utvikler B sist hentet de nyeste kildene.

   3. Utvikler B må løse konflikten. Det kan hende at funksjonene i kildekontrollsystemet i bruk kan avhjelpe denne prosessen. Ellers er følgende valg ikke gyldige.

      1. Utvikler B, kan gjennom kildekontrolloggen, hvis tilgjengelig, observere at utvikler A utførte den forrige endringen. Gjennom direkte kommunikasjon kan de diskutere hver endring. Deretter trenger utvikler B bare å oppdatere organisasjonen med den avtalte løsningen. Utvikler B eksporterer, pakker ut og overskriver deretter den motstridende filen og sender inn.

      2. Tillat at kildekontroll overskriver den lokale filen. Utvikler B pakker løsningen og importerer den til organisasjonen. Deretter vurderer han statusen til visningen og tilpasser den på nytt etter behov. Deretter kan utvikler B eksportere, pakke ut og overskrive filen som er i konflikt.

      3. Hvis den forrige endringen anses som unødvendig, tillater utvikler B at kopien av filen overskriver versjonen i kildekontrollen, og sender inn.

Enten det gjelder arbeid på delte miljøer eller uavhengige miljøer, krever teamutvikling av Dataverse-løsninger at de arbeider aktivt med en felles løsning for å være oppmerksom på arbeidet til andre. Løsningspakkeverktøyet fjerner ikke dette behovet fullstendig, men det gjør det mulig å enkelt slå sammen endringer som ikke er i konflikt med hverandre, på kildekontrollnivået, og det fremhever proaktivt de nøyaktige komponentene der konflikter oppstår.

De neste delene er de generelle prosessene for effektiv bruk av løsningspakkeverktøyet i kildekontroll ved utvikling med team. Disse fungerer likt med uavhengige miljøer eller delte utviklingsmiljøer, men med delte miljøer inkluderer eksport og utpakking naturlig alle endringene som finnes i løsningen, ikke bare de som er gjort av utviklerne som utfører eksporten. På samme måte, når du importerer en løsning .zip-fil, vil den naturlige virkemåten for å overskrive alle komponenter forekomme.

Opprett en løsning

Denne fremgangsmåten identifiserer de typiske trinnene som brukes når du oppretter en løsning for første gang.

1. I en rent miljø med Dataverse oppretter du en løsning, og deretter legger du til eller oppretter komponenter etter behov.

2. Når du er klar til å sjekke inn, følger du disse trinnene.

   1. Eksporter den uadministrerte løsningen.

   2. Bruk løsningspakkeverktøyet til å pakke ut løsningen i komponentfiler.

   3. Legg til de nødvendige filene i kildekontrollen fra de utpakkede komponentfilene.

   4. Send disse endringene til kildekontrollen.

Endre en løsning

Fremgangsmåten nedenfor identifiserer de typiske trinnene som brukes ved endring av en eksisterende løsning.

1. Synkroniser eller hent de nyeste løsningskomponent-filkildene.

2. Bruk løsningspakkeverktøyet til å pakke komponentfiler i en uadministrert løsning .zip-fil.

3. Importer den uadministrerte løsningsfilen til et miljø.

4. Tilpass og rediger løsningen etter behov.

5. Når du er klar til å kontrollere endringene i kildekontrollen, følger du disse trinnene.

   1. Eksporter den uadministrerte løsningen.

   2. Bruk løsningspakkeverktøyet til å pakke ut den eksporterte løsningen i komponentfiler.

   3. Synkroniser eller hent de nyeste kildene fra kildekontrollen.

   4. Løs eventuelle konflikter.

   5. Send endringene til kildekontrollen.

   Trinn 2 og 3 må utføres før ytterligere tilpassinger gjøres i utviklingsorganisasjonen. I trinn 5 må trinn b fullføres før trinn c utføres.

Se også

Filreferanse for løsningskomponent (SolutionPackager)
SolutionPackager-verktøy
Filformater for kildekontroll