Lähteen hallinta ratkaisutiedostojen avulla

Ratkaisun paketointityökalua voi käyttää minkä tahansa lähdehallintajärjestelmän kanssa. Kun ratkaisun .zip-tiedosto on purettu kansioon, voit lisätä ja lähettää tiedostot lähdehallintajärjestelmään. Nämä tiedostot voidaan sitten synkronoida toiseen tietokoneeseen, jossa ne voidaan pakata uuteen identtiseen ratkaisun .zip-tiedostoon.

Tärkeä näkökohta käytettäessä purettuja komponenttitiedostoja lähteenhallinnassa on se, että kaikkien tiedostojen lisääminen lähteenhallintaan voi aiheuttaa tarpeetonta päällekkäisyyttä. Katso kohdasta Ratkaisukomponentin tiedostoviite, mitkä tiedostot luodaan minkäkin komponenttityypin osalta ja mitä tiedostoja suositellaan käytettäväksi lähteenhallinnassa.

Kun ratkaisuun tarvitaan lisää mukautuksia ja muutoksia, kehittäjien pitäisi muokata tai mukauttaa komponentteja olemassa olevin keinoin, viedä ne uudelleen .zip-tiedoston luomiseksi ja purkaa pakattu ratkaisutiedosto samaan kansioon.

Kun ratkaisun paketointityökalu purkaa komponenttitiedostot, se ei korvaa samannimisiä aiemmin luotuja osatiedostoja, jos tiedostojen sisällöt ovat identtiset. Lisäksi työkalu kunnioittaa komponenttitiedostojen vain luku -määritettä, ja antaa konsoli-ikkunassa varoituksen, että tiettyjä tiedostoja ei kirjoitettu. Tämän suojauksen ansiosta käyttäjä voi kuitata ulos lähteenhallinnasta vähimmäisjoukon tiedostoja, joka muuttuu. /clobber-parametrin avulla voidaan ohittaa vain luku -tiedostoja ja aiheuttaa niiden kirjoittamista tai poistamista. /allowWrite-parametrilla voidaan arvioida, mitä vaikutuksia purkutoiminnossa on ilman, että se itse asiassa aiheuttaa tiedostojen kirjoittamista tai poistamista. /allowWrite-parametrin käyttäminen selväsanaisen kirjaamisen kanssa on tehokasta.

Kun purkutoiminto on valmis ja pienimmällä mahdollisella joukolla lähteenhallinnasta ulos kuitattuja tiedostoja, kehittäjä voi lähettää muutetut tiedostot takaisin lähteenhallintaan, kuten muuntyyppiselle lähdetiedostoille tehdään.

Lähteen hallinnan tiedostomuodot

Solution Packager -työkalu tukee kahta tiedostomuotoa poimituille komponenttitiedostoille. Kun valitset oikean muodon etukäteen, sinun ei tarvitse siirtää säilön rakennetta myöhemmin.

Milloin YAML-muotoa kannattaa käyttää: Kaikissa uusissa projekteissa ja aina, kun käytät Alkuperäistä Dataverse Git -integrointia. YAML-muoto on eteenpäin yhteensopiva ja tuottaa siistin muutoshistorian.

Milloin XML-muotoa kannattaa käyttää: Vain käsiteltäessä olemassa olevia säilöjä, joissa käytetään jo XML-muotoa, tai käytettäessä vanhoja työkaluja, jotka eivät tue YAML:ää.

Ryhmäkehitys

Kun useita kehittäjiä käsittelee samaa ratkaisun komponenttia, voi syntyä ristiriita, jossa kahden kehittäjän muutokset aiheuttavat muutoksia yksittäisessä tiedostossa. Tämän esiintymistä vähennetään siten, että jokainen yksilöllisesti muokattava komponentti tai alikomponentti on hajotettuna erilliseen tiedostoon. Katso seuraavaa esimerkkiä.

1. Kehittäjät A ja B käsittelevät samaa ratkaisua.

2. Itsenäisissä tietokoneissa ne saavat uusimmat ratkaisun lähteet lähteen hallinnasta, pakkaamisesta ja tuovat hallitsemattoman ratkaisun, .zip -tiedoston riippumattomiin Microsoft Dataverse organisaatioihin.

3. Kehittäjä A mukauttaa Aktiivisten yhteystietojen järjestelmänäkymää ja Yhteyshenkilö-entiteetin päälomaketta.

4. Kehittäjä B mukauttaa Tili-entiteetin päälomakkeen ja muuttaa yhteyshenkilöiden hakunäkymää.

5. Molemmat kehittäjät vievät hallitsemattoman ratkaisun .zip-tiedoston ja purkavat sen.

   1. Kehittäjä A:n on tarkistettava yksi tiedosto Yhteyshenkilö-päälomakkeelle ja yksi tiedosto Aktiivisten yhteystietojen näkymälle.

   2. Kehittäjän A on kuitattava yksi tiedosto tilin päälomaketta varten sekä yhden tiedoston yhteyshenkilön haku -näkymää varten.

6. Molemmat kehittäjät voivat toimittaa muutoksensa missä tahansa järjestyksessä, koska ne koskivat eri tiedostoja.

7. Kun molemmat lähetykset on suoritettu, he voivat toistaa vaiheen #2 ja jatkaa sitten muutosten tekemistä itsenäisissä organisaatioissaan. Kummallakin on kumpikin muutosjoukko, eikä heidän omaa työtään ole korvattu.

Edellinen esimerkki toimii vain silloin, kun muutokset kohdistuvat erillisiin tiedostoihin. On väistämätöntä, että toisistaan riippumattomat mukautukset edellyttävät muutoksia yksittäisessä tiedostossa. Aiemmin näytetyn esimerkin perusteella kehittäjä B on mukauttanut "Aktiiviset yhteyshenkilöt" -näkymää kehittäjä A:n mukauttaessa sitä. Tässä uudessa esimerkissä tapahtumien järjestys on tärkeä. Oikea prosessi tämän pulman ratkaisemiseen kuvataan tässä kirjoitettuna kokonaisuudessaan.

1. Kehittäjät A ja B käsittelevät samaa ratkaisua.

2. Riippumattomissa tietokoneissa molemmat saavat viimeisimmät lähteet ratkaisun lähteenhallinnalle , pakkaavat ja tuovat hallitsemattoman ratkaisun .zip-tiedoston riippumattomiin organisaatioihin.

3. Kehittäjä A mukauttaa Aktiivisten yhteystietojen järjestelmänäkymää ja Yhteystieto-taulukon päälomaketta.

4. Kehittäjä B mukauttaa Tili-taulukon päälomakkeen ja muuttaa aktiivisten yhteyshenkilöiden hakunäkymää.

5. Molemmat kehittäjät vievät hallitsemattoman ratkaisun .zip-tiedoston ja purkavat sen.

   1. Kehittäjä A:n on tarkistettava yksi tiedosto Yhteyshenkilö-päälomakkeelle ja yksi tiedosto Aktiivisten yhteystietojen näkymälle.

   2. Kehittäjä B:n on tarkistettava yksi tiedosto Tili-päälomakkeesta ja yksi tiedosto "Aktiiviset yhteystiedot" -näkymää varten.

6. Kehittäjä A on ensin valmis.

   1. Ennen kuin kehittäjä A toimittaa lähteenhallintaan, hänen on hankittava viimeisimmät lähteet sen varmistamiseksi, että mikään aiempi sisäänkuittaus ole ristiriidassa hänen muutostensa kanssa.

   2. Ristiriitoja ei ole, joten kehittäjä A voi toimittaa.

7. Sovellus kehittäjä B on valmis seuraavana kehittäjän A jälkeen.

   1. Ennen kuin kehittäjä B toimittaa, hänen on hankittava viimeisimmät lähteet sen varmistamiseksi, että mikään aiempi sisäänkuittaus ole ristiriidassa hänen muutostensa kanssa.

   2. Tässä on ristiriita, koska "Aktiivisten yhteystietojen" tiedostoa on muokattu sen jälkeen, kun kehittäjä B viimeksi haki uusimmat lähteet.

   3. Kehittäjän B on sovitettava ristiriita yhteen. On mahdollista, että käytettävän lähdeohjausjärjestelmän ominaisuudet voivat auttaa tässä prosessissa. Muussa tapauksessa seuraavat valinnat ovat toteuttamiskelpoisia.

      1. Kehittäjä B voi lähteenhallinnan historian, jos se on käytettävissä, perusteella havaita, että kehittäjä A teki aiemman muutoksen. He voivat keskustella kustakin muutoksesta suoran yhteyden välityksellä. Tämän jälkeen kehittäjän B on päivitettävä organisaatio sovitulla ratkaisulla. Tämän jälkeen kehittäjä B vie, purkaa ja korvaa ristiriitaiset tiedostot ja lähettää ne.

      2. Salli lähteenhallinnan korvata paikallinen tiedosto. Kehittäjä B pakkaa ratkaisun ja tuo sen organisaatioonsa, arvioi näkymän tilan ja mukauttaa sen uudelleen tarpeen mukaan. Seuraavaksi kehittäjä B voi viedä, purkaa ja korvata ristiriitaisen tiedoston.

      3. Jos aiempi muutos katsotaan tarpeettomaksi, kehittäjä B sallii hänen tiedostokopionsa korvata lähdehallinnassa olevan version ja lähettää.

Oli kyseessä työskentely jaetussa ympäristössä tai erillisissä ympäristössä, Dataverse-ratkaisujen ryhmäkehitys edellyttää niiden työskentelemistä yhteisen ratkaisun parissa, jotta muiden työstä oltaisiin tietoisia. Ratkaisun paketointityökalu ei täysin poista tätä tarvetta, mutta se mahdollistaa epäristiriitaisten muutosten helpon yhdistämisen lähteenhallinnan tasolla ja koostaa ennakoivasti yhdenmukaisia komponentteja, joissa konflikteja on muodostunut.

Seuraavissa osissa käsitellään yleisiä prosesseja, joilla voidaan tehokkaasti käyttää ratkaisun paketointityökalua lähteenhallinnassa, kun kehitystä tehdään ryhmissä. Nämä toimivat yhtä lailla itsenäisten ympäristöjen tai yhteisten kehitysympäristöjen kanssa, vaikka jaetuissa ympäristöissä vieminen ja purkaminen sisältää luontaisesti kaikki ratkaisussa olevat muutokset eikä vain niitä, jotka viennin suorittava kehittäjä on tehnyt. Samoin, kun ratkaisun .zip-tiedostoa tuodaan, tapahtuu luonnollinen toimintatapa korvata kaikki komponentit.

Ratkaisun luominen

Tässä menettelyssä määritetään tavalliset vaiheet, joita käytetään, kun ratkaisu luodaan ensimmäistä kertaa.

1. Jos kyseessä on puhdas ympäristö, luo ratkaisu Dataversen avulla ja lisää tai luo komponentteja sitten tarpeen mukaan.

2. Kun olet valmiina kuittaamaan sisään, noudata seuraavia ohjeita.

   1. Vie hallitsematon ratkaisu.

   2. Pura ratkaisu komponenttitiedostoihin käyttämällä ratkaisun paketointityökalua.

   3. Lisää tarpeelliset tiedostot näistä komponenttitiedostoista lähteenhallintaan.

   4. Lähetä nämä muutokset lähteenhallintaan.

Ratkaisun muokkaaminen

Seuraavassa menettelyssä määritetään tavalliset vaiheet, joita käytetään muokattaessa olemassa olevaa ratkaisua.

1. Synkronoi tai hae uusimmat ratkaisunkomponentin tiedostolähteet.

2. Käytä ratkaisun paketointityökalua ja pakkaa komponenttitiedostot hallitsemattoman ratkaisun .zipi-tiedostoon.

3. Tuo hallitsemattoman ratkaisun tiedosto ympäristöön.

4. Mukauta ja muokkaa ratkaisua tarpeen mukaan.

5. Kun olet valmis tarkistamaan muutokset lähteenhallintaan, noudata seuraavia ohjeita.

   1. Vie hallitsematon ratkaisu.

   2. Pura viety ratkaisu komponenttitiedostoihin käyttämällä ratkaisun paketointityökalua.

   3. Synkronoit tai hanki viimeisimmät lähteet lähteenhallinnasta.

   4. Ratkaise mahdolliset ristiriidat.

   5. Lähetä muutokset lähteenhallintaan.

   Vaiheet 2 ja 3 on suoritettava, ennen kuin kehitysorganisaatiossa tehdään lisää mukautuksia. Vaiheen 5 aikana vaihe b on suoritettava ennen vaihetta c.

Katso myös

Ratkaisuosan tiedostoviittaus (SolutionPackager)
SolutionPackager-työkalu
Lähteen hallinnan tiedostomuodot