opomba,
Dostop do te strani zahteva pooblastilo. Poskusite se vpisati alispremeniti imenike.
Dostop do te strani zahteva pooblastilo. Poskusite lahko spremeniti imenike.
Orodje Solution Packager se lahko uporablja s katerim koli sistemom za nadzor izvorne kode. Ko je datoteka .zip z rešitvijo razpakirana v mapo, dodajte datoteke in jih pošljite v sistem za nadzor izvorne kode. Te datoteke se lahko nato sinhronizirajo v drugem računalniku, kjer jih lahko zapakirate v novo enako datoteko .zip rešitve.
Pomemben vidik pri uporabi izvlečenih komponentnih datotek v nadzoru izvorne kode je, da lahko dodajanje vseh datotek v nadzor izvorne kode povzroči nepotrebno podvajanje. Če želite odkriti, katere datoteke so ustvarjene za posamezno vrsto komponente in katere datoteke so priporočene za uporabo v nadzoru izvorne kode, obiščite Referenčni priročnik za datoteke komponent rešitve .
Ker so za rešitev potrebne nadaljnje prilagoditve in spremembe, morajo razvijalci urediti ali prilagoditi komponente z obstoječimi sredstvi, jih znova izvoziti, da ustvarijo datoteko .zip, in ekstrahirati stisnjeno datoteko rešitve v isto mapo.
Pomembno
Razen razdelkov, opisanih v razdelku Kdaj urediti datoteko s prilagoditvami, ročno urejanje izvlečenih datotek komponent in datotek .zip ni podprto.
Ko orodje Solution Packager izvleče datoteke komponent, ne prepiše obstoječih datotek komponent z istim imenom, če je vsebina datotek enaka. Poleg tega orodje spoštuje atribut »samo za branje« v komponentnih datotekah in v oknu konzole prikaže opozorilo, da določene datoteke niso bile zapisane. Ta zaščita uporabniku omogoča, da iz nadzora izvorne kode preveri minimalni nabor datotek, ki se spreminjajo. Parameter /clobber se lahko uporabi za preglasitev, kar povzroči, da se datoteke samo za branje zapišejo ali izbrišejo. Parameter /allowWrite se lahko uporabi za oceno vpliva postopka ekstrakcije, ne da bi se morale datoteke dejansko zapisati ali izbrisati. Uporaba parametra /allowWrite s podrobnim beleženjem je učinkovita.
Ko je postopek ekstrakcije končan z minimalnim naborom datotek, rezerviranih iz nadzora izvorne kode, lahko razvijalec spremenjene datoteke pošlje nazaj v nadzor izvorne kode, tako kot to stori s katero koli drugo vrsto izvorne datoteke.
Formati datotek za nadzor izvorne kode
Orodje Solution Packager podpira dva datotečna formata za izvlečene datoteke komponent. Z izbiro pravega formata na začetku se izognete kasnejši migraciji strukture repozitorija.
| XML format (dediščina) | YAML format za nadzor izvorne kode | |
|---|---|---|
| Manifest rešitve | Other\Solution.xml + Other\Customizations.xml |
solutions/<name>/solution.yml in podpora datotekam YAML |
| Berljivost | Verbose XML | Kompaktni YAML — lažji za branje in ocenjevanje |
| Kakovost diferencial v Gitu | Velike XML razlike | Minimalni, osredotočeni diferenciali |
| Večrešilni repozitorij | Ni podprto | Podprto — več rešitev si deli eno mapo |
| Canvas aplikacije (.msapp) | Ni podprto | Podprto |
| Sodobni tokovi | Ni podprto | Podprto |
| Integracija z nativnim Gitom | Ni uporabljeno | Vedno uporabljeno — Git integracija vedno piše YAML |
Kdaj uporabiti YAML format: Za vse nove projekte in kadar koli uporabljate nativno integracijo Dataverse z Gitom. Format YAML je združljiv naprej in omogoča čistejšo zgodovino sprememb.
Kdaj uporabiti XML format: Samo pri delu z obstoječimi repozitoriji, ki že uporabljajo XML format, ali pri uporabi starejših orodij, ki ne podpirajo YAML.
opomba,
Ko commitirate rešitve z uporabo nativne Git integracije v Power Apps, so vedno shranjene v YAML formatu za upravljanje izvorne kode. Za ročno pakiranje ali razpakiranje tega vira z uporabo SolutionPackager ali pac solution pack, mora mapa slediti strukturi map YAML. Več informacij: Orodje SolutionPackager — formati datotek za nadzor izvorne kode
Razvoj ekip
Ko na isti komponenti rešitve dela več razvijalcev, lahko pride do konflikta, pri katerem spremembe dveh razvijalcev povzročijo spremembe v eni sami datoteki. Ta pojav se minimizira z razgradnjo vsake posamezne komponente ali podkomponente, ki jo je mogoče urejati, v ločeno datoteko. Oglejte si naslednji primer:
Razvijalca A in B urejata isto rešitev.
Na neodvisnih računalnikih oba dobita najnovejše vire rešitve iz nadzora izvorne različice, zapakirata in uvozita neupravljano rešitev .zip datoteko v neodvisne Microsoft Dataverse organizacije.
Razvijalec A prilagodi sistemski pogled "Aktivni kontakti" in glavni obrazec za entiteto Kontakt.
Razvijalec B prilagodi glavni obrazec za entiteto Račun in spremeni »Pogled iskanja stika«.
Oba razvijalca izvozita datoteko .zip neupravljane rešitve in jo ekstrahirata.
Razvijalec A bo moral izposoditi eno datoteko za glavni obrazec Kontakt in eno datoteko za pogled "Aktivni kontakti".
Razvijalec B bo moral rezervirati eno datoteko za glavni obrazec računa in eno datoteko za »Pogled iskanja stikov«.
Oba razvijalca sta lahko oddala spremembe v poljubnem vrstnem redu, saj so se njune spremembe dotikale ločenih datotek.
Ko oba zaključita pošiljanje, lahko ponovita 2. korak in nato naprej izvajata spremembe v svojih neodvisnih organizacijah. Vsak od njiju ima oba niza sprememb, brez prepisa lastnega dela.
Prejšnji primer je mogoč le, če so spremembe izvedene za ločene datoteke. Neizogibno je, da neodvisne prilagoditve zahtevajo spremembe znotraj ene same datoteke. Na podlagi prej prikazanega primera si predstavljajte, da je razvijalec B prilagodil pogled "Aktivni stiki", medtem ko ga je razvijalec A prav tako prilagajal. V tem novem primeru postane pomemben vrstni red dogodkov. Pravilen postopek za rešitev te zagate je v celoti opisan tukaj.
Razvijalca A in B urejata isto rešitev.
V neodvisnih računalnikih oba pridobita najnovejšo izvorno kodo rešitve iz nadzora izvorne kode, zapakirata datoteko .zip neupravljane rešitve in jo uvozita v neodvisni organizaciji.
Razvijalec A prilagodi sistemski pogled "Aktivni stiki" in glavni obrazec za tabelo Kontakt.
Razvijalec B prilagodi glavni obrazec za tabelo Račun in spremeni »Aktivni stiki«.
Oba razvijalca izvozita datoteko .zip neupravljane rešitve in jo ekstrahirata.
Razvijalec A bo moral izposoditi eno datoteko za glavni obrazec Kontakt in eno datoteko za pogled "Aktivni kontakti".
Razvijalec B bo moral izposoditi eno datoteko za glavni obrazec računa in eno datoteko za pogled "Aktivni stiki".
Razvijalec A je prvi pripravljen.
Preden razvijalec A predloži spremembe v sistem za nadzor izvorne kode, mora pridobiti najnovejše izvorne kode, da se prepriča, da predhodne prijave niso v nasprotju z njegovimi spremembami.
Ni konfliktov, zato lahko razvijalec A odda zahtevo.
Razvijalec B je pripravljen za razvijalcem A.
Preden razvijalec B odda spremembo, mora pridobiti najnovejše vire, da se prepriča, da predhodne prijave ne nasprotujejo njegovim spremembam.
Prišlo je do konflikta, ker je bila datoteka za "Aktivni stiki" spremenjena odkar je razvijalec B nazadnje pridobil najnovejše vire.
Razvijalec B mora odpraviti spor. Možno je, da zmogljivosti uporabljenega sistema za nadzor izvorne kode pomagajo pri tem procesu; sicer so vse naslednje možnosti izvedljive.
Razvijalec B lahko prek zgodovine nadzora izvorne kode, če je na voljo, opazi, da je razvijalec A opravil predhodno spremembo. Prek neposredne komunikacije se lahko pogovorita o vsaki spremembi. Razvijalec B mora nato organizaciji le še sporočiti dogovorjeno resolucijo. Razvijalec B nato izvozi, izvleče in prepiše konfliktno datoteko ter jo odda.
Dovoli nadzoru izvorne kode, da prepiše lokalno datoteko. Razvijalec B zapakira rešitev in jo uvozi v svojo organizacijo, nato pa oceni stanje pogleda in ga po potrebi ponovno prilagodi. Nato lahko razvijalec B izvozi, izvleče in prepiše konfliktno datoteko.
Če se prejšnja sprememba oceni kot nepotrebna, razvijalec B dovoli, da njegova kopija datoteke prepiše različico v nadzoru izvorne kode, in jo odda.
Ne glede na to, ali delate v skupnem ali neodvisnem okolju, timski razvoj rešitev zahteva, da se tisti, ki aktivno delajo na skupni rešitvi, zavedajo dela drugih. Dataverse Orodje Solution Packager te potrebe ne odpravi v celoti, vendar omogoča enostavno združevanje nekonfliktnih sprememb na ravni nadzora izvorne kode in proaktivno poudarja jedrnate komponente, kjer se pojavijo konflikti.
Naslednji razdelki so splošni postopki za učinkovito uporabo orodja Solution Packager v nadzoru izvorne kode pri razvoju z ekipami. To deluje enako z neodvisnimi okolji ali deljenimi razvojnimi okolji, čeprav pri deljenih okoljih izvoz in izvleček seveda vključujeta vse spremembe, prisotne v rešitvi, ne le tistih, ki jih je naredil razvijalec, ki je izvedel izvoz. Podobno se pri uvozu datoteke .zip rešitve pojavi naravno vedenje, da se vse komponente prepišejo.
Ustvarjanje rešitve
Ta postopek določa tipične korake, ki se uporabljajo pri prvem ustvarjanju rešitve.
V čistem okolju z Dataverse ustvarite rešitev in nato po potrebi dodajte ali ustvarite komponente.
Ko ste pripravljeni na prijavo, sledite tem korakom.
Izvozite neupravljano rešitev.
Z orodjem Solution Packager ekstrahirajte rešitev v datoteke komponent.
Iz teh ekstrahiranih datotek komponent dodajte potrebne datoteke v nadzor izvorne kode.
Te spremembe pošljite v nadzor izvorne kode.
Spreminjanje rešitve
Naslednji postopek določa običajne korake, ki se uporabljajo pri spreminjanju obstoječe rešitve.
Sinhronizirajte najnovejše vire datotek komponent rešitve ali jih pridobite.
Z orodjem Solution Packager zapakirajte datoteke komponent v datoteko .zip neupravljane rešitve.
Uvozite datoteko neupravljane rešitve v okolje.
Po potrebi prilagodite in uredite rešitev.
Ko ste pripravljeni preveriti spremembe v nadzoru izvorne kode, sledite tem korakom.
Izvozite neupravljano rešitev.
Z orodjem Solution Packager ekstrahirajte izvoženo rešitev v datoteke komponent.
Sinhronizirajte najnovejše vire iz nadzora izvorne kode ali jih pridobite.
Če obstajajo spori, jih odpravite.
Spremembe pošljite v nadzor izvorne kode.
2. in 3. korak je treba izvesti, preden se v razvojni organizaciji pojavijo nadaljnje prilagoditve. V 5. koraku je treba korak b izvesti pred korakom c.
Glejte tudi
Referenca datoteke komponente rešitve (SolutionPackager)
Orodje SolutionPackager
Formati datotek za nadzor izvorne kode