Jaa

Lähteen hallinta ratkaisutiedostojen avulla

  • Artikkeli

SolutionPackager-työ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.

Tärkeä

Lukuun ottamatta osia, jotka on kuvattu Mukautustiedostojen muokkaamisen aika -kohdassa, purettujen komponenttitiedostojen ja .zip-tiedostojen muokkaamista ei tueta.

Kun SolutionPackager-työ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. Näin 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.

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. Riippumattomissa tietokoneissa molemmat saavat viimeisimmät lähteet ratkaisun lähteenhallinnalle , pakkaavat ja tuovat hallitsemattoman ratkaisun .zip-tiedoston riippumattomiin Microsoft Dataverse -organisaatioihin.

  3. Kehittäjä A mukauttaa Aktiiviset yhteyshenkilöt -järjestelmänäkymän sekä Yhteyshenkilö-entiteetin päälomakkeen.

  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 puretun kohteen.

    1. Kehittäjän A on kuitattava yksi tiedosto yhteyshenkilön päälomaketta varten sekä yhden tiedoston Aktiiviset yhteyshenkilöt -näkymää varten.

    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. Yllä olevan esimerkin perusteella kannattaa harkita, että kehittäjä B mukauttaa aktiivisten yhteyshenkilöiden -näkymää, kun myös kehittäjä A on mukauttanut sitä. Tässä uudessa esimerkissä tapahtumien järjestys on tärkeä. Oikea prosessi ratkaisemaan tämän pulman kokonaisuudessaan on seuraava.

  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 Aktiiviset yhteyshenkilöt -järjestelmänäkymän sekä Yhteyshenkilö-entiteetin päälomakkeen.

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

  5. Kumpikin kehittäjä vie hallitsemattoman ratkaisun. zip-tiedosto ja purkaminen.

    1. Kehittäjän A on kuitattava yksi tiedosto yhteyshenkilön päälomaketta varten sekä yhden tiedoston Aktiiviset yhteyshenkilöt -näkymää varten.

    2. Kehittäjän A on kuitattava yksi tiedosto tilin päälomaketta varten sekä yhden tiedoston Aktiiviset yhteyshenkilöt -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 Aktiiviset yhteyshenkilöt -tiedostoa on muokattu sen jälkeen, kun kehittäjä B viimeksi on hakenut viimeisimmät 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ä, kautta nähdä, 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 voidaan katsoa tarpeettomaksi, kehittäjä B sallii hänen tiedostokopionsa korvata lähdehallinnassa olevan version ja lähettää.

Oli kyseessä työskentely jaetussa organisaatiossa tai erillisissä organisaatioissa, Dataverse -ratkaisujen ryhmäkehitys edellyttää niiden työskentelemistä yhteisen ratkaisun parissa, jotta muiden työstä oltaisiin tietoisia. SolutionPackager-työ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ää SolutionPackager-työkalua lähteenhallinnassa, kun kehitystä tehdään ryhmissä. Nämä toimivat yhtä lailla itsenäisten organisaatioiden tai yhteisten kehitysorganisaatioiden kanssa, vaikka jaetuissa organisaatioissa 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

Seuraavassa menettelyssä määritetään tavalliset vaiheet, joita käytetään luotaessa ratkaisua ensimmäisen kerran.

  1. Jos kyseessä on puhdas organisaatio, luo ratkaisu Dataverse -palvelimella ja lisää tai luo komponentteja sitten tarpeen mukaan.

  2. Kun olet valmiina kuittaamaan sisään, tee seuraavaa.

    1. Vie hallitsematon ratkaisu.

    2. Pura ratkaisu komponenttitiedostoihin käyttämällä SolutionPackager-työ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ä SolutionPackager-työkalua ja pakkaa komponenttitiedostot hallitsemattoman ratkaisun .zipi-tiedostoon.

  3. Tuo hallitsemattoman ratkaisun tiedosto organisaatioon.

  4. Mukauta ja muokkaa ratkaisua tarpeen mukaan.

  5. Kun olet valmis tarkistamaan muutokset lähteenhallintaan, toimi seuraavasti.

    1. Vie hallitsematon ratkaisu.

    2. Pura viety ratkaisu komponenttitiedostoihin käyttämällä SolutionPackager-työ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

Ratkaisun osan tiedostoviite (SolutionPackager)
SolutionPackager-työkalu