Kildekontroll med løsningsfiler
SolutionPackager-verktø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. Se 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.
Viktig
Med unntak av delene som er beskrevet i Når du skal redigere tilpassingsfilen, støttes ikke manuell redigering av utpakkede komponentfiler og zip-filer.
Når SolutionPackager-verktøyet pakker ut komponentfilene, vil den 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. Dette 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.
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.
Utvikler A og B arbeider begge med samme løsning.
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 Microsoft Dataverse-organisasjoner.
Utvikler A tilpasser systemvisningen "Aktive kontakter" og hovedskjemaet for kontakt-enheten.
Utvikler B tilpasser hovedskjemaet for Forretningsforbindelser-enheten og endrer "Oppslagsvisning for kontakt".
Begge utviklerne eksporterer en uadministrert løsning .zip-fil og pakker ut.
Utvikler A må sjekke ut én fil for hovedskjemaet for kontakter, og én fil for "Aktive kontakter"-visningen.
Utvikler B må sjekke ut én fil for hovedskjemaet for forretningsforbindelse, og én fil for "Oppslagsvisning for kontakt".
Begge utviklerne kan sende inn, i hvilken som helst rekkefølge, siden de respektive endringene berørte separate filer.
Når begge innsendinger er fullført, kan de gjenta trinn 2 og deretter fortsette å gjøre flere endringer i de uavhengige organisasjonene. Det har hver begge sett med endringer, uten overskrivinger 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 vises ovenfor, må du ta hensyn til at utvikler B har tilpasset "Aktive kontakter"-visningen, mens utvikler A også tilpasser den. I dette nye eksemplet blir hendelsesrekkefølgen viktig. Riktig prosess for å løse dette problemet, skrevet fullt ut, er som følger.
Utvikler A og B arbeider begge med samme løsning.
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.
Utvikler A tilpasser systemvisningen "Aktive kontakter" og hovedskjemaet for kontakt-enheten.
Utvikler B tilpasser hovedskjemaet for Forretningsforbindelser-enheten og endrer "Aktive kontakter".
Begge utviklerne eksporterer en uadministrert løsning. zip-fil og pakk ut.
Utvikler A må sjekke ut én fil for hovedskjemaet for kontakter, og én fil for "Aktive kontakter"-visningen.
Utvikler B må sjekke ut én fil for hovedskjemaet for forretningsforbindelse, og én fil for "Aktive kontakter"-visningen.
Utvikler A er klar først.
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.
Det er ingen konflikter, og utvikler A kan derfor sende inn.
Utvikler B er klar etter utvikler A.
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.
Det er en konflikt fordi filen for "Aktive kontakter" har blitt endret etter at utvikler B hentet de nyeste kildene sist.
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.
Utvikler B, kan gjennom kildekontrolloggen, hvis tilgjengelig, se 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.
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.
Hvis den forrige endringen kan anses unødvendig, tillater utvikler B at kopien av filen overskriver versjonen i kildekontrollen, og sender inn.
Enten det gjelder arbeid på delte organisasjoner eller uavhengige organisasjoner, krever teamutvikling av Dataverse-løsninger at de arbeider aktivt med en felles løsning for å være oppmerksom på arbeidet til andre. SolutionPackager-verktø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 det har oppstått konflikt.
De neste delene er de generelle prosessene for effektiv bruk av SolutionPackager-verktøyet i kildekontroll ved utvikling med team. Disse fungerer likt med uavhengige organisasjoner eller delte utviklingsorganisasjoner, men med delte organisasjoner vil eksport og utpakking naturlig inkludere 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.
Opprette en løsning
Fremgangsmåten nedenfor identifiserer de typiske trinnene som brukes ved førstegangs oppretting av en løsning.
I en ren organisasjon oppretter du en løsning på Dataverse-serveren, og deretter legger du til eller oppretter komponenter etter behov.
Når du er klar til å sjekke inn, gjør du følgende:
Eksporter den uadministrert løsningen.
Bruk SolutionPackager-verktøyet til å pakke ut løsningen i komponentfiler.
Legg til de nødvendige filene i kildekontrollen fra de utpakkede komponentfilene.
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.
Synkroniser eller hent de nyeste løsningskomponent-filkildene.
Bruk SolutionPackager-verktøyet til å pakke komponentfiler i en uadministrert løsning .zip-fil.
Importer den uadministrerte løsningsfilen til en organisasjon.
Tilpass og rediger løsningen etter behov.
Når du er klar til å kontrollere endringene i kildekontrollen, gjør du følgende:
Eksporter den uadministrert løsningen.
Bruk SolutionPackager-verktøyet til å pakke ut den eksporterte løsningen i komponentfiler.
Synkroniser eller hent de nyeste kildene fra kildekontrollen.
Løs eventuelle konflikter.
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