Lähtekeskkonna juhtimine lahendusfailidega

Lahenduste pakendamise tööriista saab kasutada mis tahes versioonikontrollisüsteemiga. Pärast lahenduse .zip-faili kausta lahtipakkimist lisage failid oma versioonikontrollisüsteemi ja esitage need sinna. Neid faile saab seejärel sünkroonida mõnes muus arvutis, kus neid saab pakkida uude identsesse lahenduse ZIP-faili.

Oluline aspekt ekstraheeritud komponentfailide kasutamisel versioonikontrollis on see, et kõigi failide lisamine versioonikontrolli võib põhjustada tarbetut dubleerimist. Iga komponenditüübi jaoks genereeritud failid ja versioonikontrollis kasutamiseks soovitatavad failid leiate lahenduse komponendi failiviitest .

Kuna lahenduse jaoks on vaja täiendavaid kohandusi ja muudatusi, peaksid arendajad olemasolevaid vahendeid kasutades komponente redigeerima või kohandama, ZIP-faili loomiseks uuesti eksportima ja tihendatud lahendusefaili samasse kausta lahti pakkima.

Oluline

Välja arvatud jaotises Millal kohandamisfaili muuta? kirjeldatud jaotised, ei toetata ekstraheeritud komponentide failide ja .zip-failide käsitsi muutmist.

Kui lahenduste pakendamise tööriist komponentfailid ekstraktib, ei kirjuta see samanimelisi olemasolevaid komponentfaile üle, kui failide sisu on identne. Lisaks austab tööriist komponentfailide kirjutuskaitstud atribuuti, kuvades konsooliaknas hoiatuse, et teatud faile ei kirjutatud. See kaitse võimaldab kasutajal lähtekoodi haldamise kaudu kontrollida minimaalset muutuvate failide hulka. Parameetrit /clobber saab kasutada kirjutuskaitstute failide kirjutamiseks või kustutamiseks. Parameetrit /allowWrite saab kasutada lahti pakkimise mõju hindamiseks, ilma et see tegelikult põhjustaks failide kirjutamist või kustutamist. Parameetri /allowWrite kasutamine koos paljusõnalise logimisega on tõhus.

Pärast seda, kui ekstraktimistoiming on minimaalse failide hulgaga lähtekoodikontrollist välja võetud, saab arendaja muudetud failid tagasi lähtekoodikontrolli esitada, nagu seda tehakse mis tahes muud tüüpi lähtekoodifailidega.

Meeskonna arendamine

Kui sama lahenduskomponendi kallal töötab mitu arendajat, võib tekkida konflikt, kus kahe arendaja muudatused põhjustavad muudatusi ühes failis. Selle toimumise minimeerimiseks pööratakse iga eraldi redigeeritav komponent või alamkomponent tagasi eraldi failiks. Vaadake järgmist näidet.

1. Arendajad A ja B töötavad mõlemad sama lahenduse kallal.

2. Sõltumatutes arvutites saavad nad lahenduse uusimad allikad lähtekeskkonna juhtimisest ning pakivad ja impordivad mittehallatava lahenduse ZIP-faili sõltumatutesse Microsoft Dataverse'i organisatsioonidesse.

3. Arendaja A kohandab süsteemivaadet „Aktiivsed kontaktid” ja olemi Kontakt põhivormi.

4. Arendaja B kohandab konto üksuse põhivormi ja muudab kontakti otsinguvaadet.

5. Mõlemad arendajad ekspordivad mittehallatava lahenduse ZIP-faili ja pakivad selle lahti.

   1. Arendaja A peab välja möllima ühe faili Kontakti põhivormi jaoks ja ühe faili vaate „Aktiivsed kontaktid” jaoks.

   2. Arendaja B peab välja registreerima ühe faili konto põhivormi ja ühe faili kontaktide otsinguvaate jaoks.

6. Mõlemad arendajad võivad esitada suvalises järjekorras, kuna nende vastavad muudatused puudutasid eraldi faile.

7. Kui mõlemad esitamised on lõpule viidud, saavad nad korrata juhist #2 ja seejärel jätkata täiendavate muudatuste tegemist oma sõltumatutes organisatsioonides. Mõlemal on muudatuste komplektid, ilma et nad oleks oma tööd üle kirjutanud.

Eelmine näide kehtib ainult siis, kui muudatused on tehtud eraldi failides. On paratamatu, et sõltumatud kohandused nõuavad muudatusi ühe faili piires. Eelneva näite põhjal oletame, et arendaja B kohandas vaadet „Aktiivsed kontaktid” samal ajal, kui arendaja A seda samuti kohandas. Selles uues näites muutub tähtsamaks sündmuste järjekord. Selle olukorra õige lahendamise protsess, mis on täielikult välja kirjutatud, on siin kirjeldatud.

1. Arendajad A ja B töötavad mõlemad sama lahenduse kallal.

2. Sõltumatutes arvutites saavad nad lahenduse uusimad allikad lähtekeskkonna juhtimisest ning pakivad ja impordivad mittehallatava lahenduse ZIP-faili sõltumatutesse organisatsioonidesse.

3. Arendaja A kohandab süsteemivaadet „Aktiivsed kontaktid” ja kontaktide tabeli põhivormi.

4. Arendaja B kohandab konto tabeli põhivormi ja muudab valikut „Aktiivsed kontaktid”.

5. Mõlemad arendajad ekspordivad mittehallatava lahenduse ZIP-faili ja pakivad selle lahti.

   1. Arendaja A peab välja möllima ühe faili Kontakti põhivormi jaoks ja ühe faili vaate „Aktiivsed kontaktid” jaoks.

   2. Arendaja B peab välja möllima ühe faili Konto põhivormi jaoks ja ühe faili vaate „Aktiivsed kontaktid” jaoks.

6. Arendaja A on toimingud esimesena lõpule viinud.

   1. Enne kui arendaja A esitab versioonikontrollile oma versiooniuuendused, peab ta hankima uusimad lähtekoodid, et veenduda, et varasemad registreerimised ei satuks vastuollu nende muudatustega.

   2. Konflikte pole, seega saab arendaja A esitada.

7. Arendaja B saab toimingutega valmis arendaja A järel.

   1. Enne esitamist peab arendaja B hankima uusimad lähtekoodid, et veenduda, et varasemad registreerimised ei satuks vastuollu nende muudatustega.

   2. Tekkis konflikt, kuna faili "Aktiivsed kontaktid" on muudetud pärast seda, kui arendaja B viimati uusimad lähtekoodid alla laadis.

   3. Arendaja B peab konflikti lahendama. Võimalik, et kasutatava versioonikontrollisüsteemi võimalused saavad seda protsessi abistada; vastasel juhul on kõik järgmised valikud teostatavad.

      1. Arendaja B saab versioonikontrolli ajaloo kaudu (kui see on saadaval) jälgida, et arendaja A tegi eelmise muudatuse. Otsese suhtluse kaudu saavad nad arutada iga tehtava muudatuse üle. Seejärel peab arendaja B organisatsioonile ainult kokkulepitud lahenduse edastama. Seejärel ekspordib, eraldab ja kirjutab arendaja B konflikti tekitava faili üle ning esitab selle.

      2. Luba versioonikontrollil kohalik fail üle kirjutada. Arendaja B pakib lahenduse ja impordib selle oma organisatsiooni, seejärel hindab vaate olekut ja kohandab seda vastavalt vajadusele. Järgmisena võib arendaja B konflikti tekitava faili eksportida, lahti pakkida ja üle kirjutada.

      3. Kui eelnev muudatus osutub ebavajalikuks, lubab arendaja B oma faili koopial versioonikontrollis olev versioon üle kirjutada ja esitab selle.

Olenemata sellest, kas töötatakse jagatud või iseseisvas keskkonnas, nõuab lahenduste meeskonnatöö väljatöötamine, et ühise lahenduse kallal aktiivselt töötavad isikud oleksid teadlikud teiste tööst. Dataverse Lahenduste pakendamise tööriist ei kõrvalda seda vajadust täielikult, kuid see võimaldab mittekonfliktsete muudatuste hõlpsat ühendamist lähtekoodi haldamise tasandil ning tõstab ennetavalt esile need kokkuvõtlikud komponendid, kus konfliktid tekivad.

Järgmistes osades kirjeldatakse üldiseid protsesse lahenduste pakendaja tööriista tõhusaks kasutamiseks versioonikontrollis meeskondadega arendamisel. Need toimivad võrdselt nii sõltumatute keskkondade kui ka jagatud arenduskeskkondade puhul, kuigi jagatud keskkondade puhul hõlmab eksport ja ekstraktimine loomulikult kõiki lahenduses olevaid muudatusi, mitte ainult eksporti teostava arendaja tehtud muudatusi. Samamoodi toimub lahenduse .zip-faili importimisel loomulik käitumine, kus kõik komponendid kirjutatakse üle.

Lahenduse loomine

See protseduur määratleb tüüpilised sammud lahenduse esmasel loomisel.

1. Looge puhtas keskkonnas Dataverse lahendus ja seejärel lisage või looge vajadusel komponente.

2. Kui olete sisse registreerimiseks valmis, järgige neid samme.

   1. Eksportige mittehallatav lahendus.

   2. Lahenduste pakkimise tööriista abil ekstraheerige lahendus komponentide failideks.

   3. Lisage nendest lahti pakitud komponendi failidest vajalikud failid lähtekeskkonna juhtimisse.

   4. Edastage need muudatused lähtekeskkonna juhtimisse.

Muutke lahendust

Järgmises toimingus määratakse kindlaks tüüpilised etapid, mida kasutatakse olemasoleva lahenduse muutmisel.

1. Sünkroonige või hankige uusimad lahenduse komponendi faili allikad.

2. Pakkige lahenduste pakkija tööriista abil komponentide failid haldamata lahenduse .zip-faili.

3. Importige haldamata lahenduse fail keskkonda.

4. Kohandage ja redigeerige lahendust vastavalt vajadusele.

5. Kui olete valmis muudatusi versioonikontrolli registreerima, järgige neid samme.

   1. Eksportige mittehallatav lahendus.

   2. Lahenduste pakendamise tööriista abil eraldage eksporditud lahendus komponentide failideks.

   3. Sünkroonige või hankige lähtekeskkonna juhtimise uusimad allikad.

   4. Viige vastavusse, kui esineb konflikte.

   5. Edastage need muudatused lähtekeskkonna juhtimisse.

   Enne edasiste kohanduste ilmnemist arendatavas organisatsioonis tuleb läbida 2. ja 3. etapp. 5. etapis tuleb etapp b läbida enne etappi c.

Vt ka

Lahenduse komponendi faili viide (SolutionPackager)
Lahenduste pakkimise tööriist