Avota vadība, izmantojot risinājuma failus

Solution Packager rīku var izmantot ar jebkuru avota kontroles sistēmu. Pēc tam, kad risinājums .zip fails ir izvilkts mapē, pievienojiet un iesniedziet failus avota kontroles sistēmai. Šos failus pēc tam var sinhronizēt citā datorā, kur tos var iepakot jaunā, identiskā risinājuma .zip failā.

Svarīgs aspekts, izmantojot izvilktos komponentu failus avota kontrolē, ir tas, ka visu failu pievienošana avota kontrolei var izraisīt nevajadzīgu dublēšanu. Dodieties uz Risinājuma komponenta faila atsauce , lai uzzinātu, kuri faili tiek ģenerēti katram komponenta tipam un kurus failus ieteicams izmantot avota kontrolē.

Tā kā risinājumam ir nepieciešami tālāki pielāgojumi un izmaiņas, izstrādātājiem ir jārediģē vai jāpielāgo komponenti esošajos līdzekļos, vēlreiz jāeksportē, lai izveidotu .zip formāta failu, un jāizvērš saspiestā risinājuma failu tajā pašā mapē.

Svarīgi

Izņemot sadaļas, kas aprakstītas sadaļā Kad rediģēt pielāgojumu failu, izvilkto komponentu failu un .zip failu manuāla rediģēšana netiek atbalstīta.

Kad risinājumu paveidotāja rīks izvelk komponentu failus, tas nepārraksta esošos komponentu failus ar tādu pašu nosaukumu, ja faila saturs ir identisks. Turklāt rīks ievēro tikai lasāmo atribūtu komponentu failos, konsoles logā radot brīdinājumu, ka konkrēti faili nav rakstīti. Šī aizsardzība ļauj lietotājam no avota kontroles paņemt minimālo mainīgo failu kopu. Šo /clobber parametru var izmantot, lai pārlabotu un izraisītu tikai lasāmus failus, kas jāraksta vai jāizdzēš. /allowWrite parametru var izmantot, lai novērtētu izvilkšanas darbības ietekmi, faktiski neradot iespēju rakstīt vai dzēst failus. /allowWrite parametra izmantošana ar izvērstu reģistrēšanu ir spēkā.

Pēc izvilkšanas operācijas pabeigšanas ar minimālo failu kopu, kas paņemta no avota kontroles, izstrādātājs var iesniegt mainītos failus atpakaļ avota kontrolē, tāpat kā tas tiek darīts ar jebkura cita veida avota failu.

Avota kontroles failu formāti

Risinājumu pakotāja rīks atbalsta divus failu formātus izvilktajiem komponentu failiem. Izvēloties pareizo formātu iepriekš, vēlāk jāizvairās no repozitorija struktūras migrēšanas.

	XML formāts (mantots)	YAML avota vadības formāts
Risinājuma manifests	Other\Solution.xml + Other\Customizations.xml	solutions/<name>/solution.yml un atbalsta YAML failus
Lasāmība	Izvērsts XML	Kompakts YAML — vieglāk lasāms un pārskatāms
Diff kvalitāte Git	Lielas XML atšķirības	Minimālas, fokusētas atšķirības
Vairāku risinājumu repo	Netiek atbalstīts	Atbalstīts — vairāki risinājumi koplieto vienu mapi
Audekla programmas (.msapp)	Netiek atbalstīts	Atbalsta
Mūsdienu plūsmas	Netiek atbalstīts	Atbalsta
Vietējā Git integrācija	Netiek lietots	Vienmēr tiek izmantots — Git integrācija vienmēr raksta YAML

Kad izmantot YAML formātu: Visiem jaunajiem projektiem un ikreiz, kad izmantojat vietējo Dataverse Git integrāciju. YAML formāts ir saderīgs ar nākotni un rada tīrāku izmaiņu vēsturi.

Kad izmantot XML formātu: Tikai tad, ja strādājat ar esošiem repozitorijiem, kas jau izmanto XML formātu, vai izmantojot mantotus rīkus, kas neatbalsta YAML.

Piezīmes

Kad veicat risinājumus, izmantojot vietējo Git integrāciju pakalpojumā Power Apps, tie vienmēr tiek glabāti YAML avota vadības formātā. Lai manuāli iesaiņotu vai izsaiņotu šo avotu, izmantojot SolutionPackager vai pac solution pack, mapei ir jāatbilst YAML mapju struktūrai. Papildinformācija: SolutionPackager rīks — avota kontroles failu formāti

Komandas izstrāde

Ja pie viena risinājuma komponenta strādā vairāki izstrādātāji, var rasties konflikts, kad divu izstrādātāju izmaiņu rezultātā tiek veiktas izmaiņas vienā failā. Šis notikums tiek minimizēts, katru atsevišķi rediģējamu komponentu vai apakškomponentu sastādot atsevišķā failā. Aplūkojiet šādu piemēru.

1. Izstrādātājs A un B strādā ar vienu un to pašu risinājumu.

2. Neatkarīgos datoros viņi iegūst jaunākos risinājuma avotus no avota kontroles, iesaiņo un importē nepārvaldītu risinājumu .zip failu neatkarīgās Microsoft Dataverse organizācijās.

3. Izstrādātājs A pielāgo sistēmas skatu "Aktīvās kontaktpersonas" un kontaktpersonas entītijas galveno veidlapu.

4. Izstrādātājs B pielāgo entītijas Konta galveno veidlapu un maina "Kontaktpersonu uzmeklēšanas skatu".

5. Abi izstrādātāji eksportē nepārvaldītu risinājumu .zip failu un izvelk to.

   1. Izstrādātājam A būs jāpaņem viens fails galvenajai kontaktpersonas veidlapai un viens fails skatam "Aktīvās kontaktpersonas".

   2. Izstrādātājam B būs jāpārbauda viens fails konta galvenajai veidlapai un viens fails "Kontaktu uzmeklēšanas skats".

6. Abi izstrādātāji var iesniegt jebkurā secībā, jo to attiecīgās izmaiņas skar atsevišķus failus.

7. Kad abi iesniegumi ir pabeigti, tie var atkārtot 2. soli un tad turpināt veikt tālākas izmaiņas to neatkarīgajās organizācijās. Katrā no tām ir abas izmaiņu kopas, un to darbība nav pārrakstīta.

Iepriekšējais piemērs darbojas tikai tad, ja ir izmaiņas atsevišķos failos. Ir neizbēgami, ka neatkarīgiem pielāgojumiem ir nepieciešamas izmaiņas vienā failā. Pamatojoties uz iepriekš parādīto piemēru, ņemiet vērā, ka izstrādātājs B pielāgoja skatu "Aktīvās kontaktpersonas", bet izstrādātājs A to arī pielāgoja. Šajā jaunajā piemērā notikumu secība kļūst svarīga. Pareizais process, lai samierinātu šo situāciju, kas ir pilnībā uzrakstīts, ir aprakstīts šeit.

1. Izstrādātājs A un B strādā ar vienu un to pašu risinājumu.

2. Neatkarīgos datoros viņi gan iegūst jaunākos risinājuma avotus no avota vadīklas, gan iepako un importē nepārvaldītu risinājumu .zip formāta failus neatkarīgās organizācijās.

3. Izstrādātājs A pielāgo sistēmas skatu "Aktīvās kontaktpersonas" un kontaktpersonu tabulas galveno veidlapu.

4. Izstrādātājs B pielāgo tabulas Kontu galveno formu un maina "Aktīvie kontakti".

5. Abi izstrādātāji eksportē nepārvaldītu risinājumu .zip failu un izvelk to.

   1. Izstrādātājam A būs jāpaņem viens fails galvenajai kontaktpersonas veidlapai un viens fails skatam "Aktīvās kontaktpersonas".

   2. Izstrādātājam B būs jāpaņem viens fails galvenajai veidlapai Konts un viens fails skatam "Aktīvās kontaktpersonas".

6. Vispirms ir gatavs izstrādātājs A.

   1. Pirms izstrādātājs A iesniedz avota kontrolei, viņiem ir jāiegūst jaunākie avoti, lai nodrošinātu, ka iepriekšēja reģistrēšanās nav pretrunā ar viņu izmaiņām.

   2. Konfliktu nav, tāpēc izstrādātājs A var iesniegt.

7. Izstrādātājs B ir gatavs nākamajam izstrādātājam A.

   1. Pirms izstrādātājs B iesniedz, viņiem ir jāsaņem jaunākie avoti, lai nodrošinātu, ka iepriekšēja reģistrēšanās nav pretrunā ar viņu izmaiņām.

   2. Pastāv konflikts, jo fails "Aktīvās kontaktpersonas" ir modificēts, kopš izstrādātājs B pēdējo reizi izguva jaunākos avotus.

   3. Izstrādātājs B ir jāsamierina konflikts. Iespējams, ka izmantojamās avota kontroles sistēmas iespējas var palīdzēt šim procesam; pretējā gadījumā visas šādas izvēles ir dzīvotspējīgas.

      1. Izstrādātājs B, izmantojot avota kontroles vēsturi, ja tāda ir pieejama, var novērot, ka izstrādātājs A veica iepriekšējās izmaiņas. Izmantojot tiešu saziņu, viņi var apspriest visas izmaiņas. Tad izstrādātājam B ir tikai jāatjaunina organizācija ar saskaņotu risinājumu. Pēc tam izstrādātājs B eksportē, izvelk un pārraksta konfliktējošo failu un iesniedz.

      2. Ļaujiet avota kontrolei pārrakstīt lokālo failu. Izstrādātājs B iesaiņo risinājumu un importē to savā organizācijā, pēc tam novērtē skata stāvokli un pēc vajadzības to pielāgo. Pēc tam izstrādātājs B var eksportēt, izvilkt un pārrakstīt konfliktējošo failu.

      3. Ja iepriekšējās izmaiņas tiek uzskatītas par nevajadzīgām, izstrādātājs B ļauj faila kopijai pārrakstīt versiju avota kontrolē un iesniedz.

Neatkarīgi no tā, vai strādā kopīgā vidē vai neatkarīgā vidē, risinājumu komandas izstrāde Dataverse prasa, lai aktīvi strādājošie pie kopīga risinājuma būtu informēti par citu darbu. Risinājumu iepakotāja rīks pilnībā nenovērš šo vajadzību, bet ļauj viegli apvienot nekonfliktējošas izmaiņas avota kontroles līmenī un proaktīvi izceļ kodolīgus komponentus, kuros rodas konflikti.

Nākamās sadaļas ir vispārīgie procesi, lai efektīvi izmantotu risinājumu paketētāja rīku avota kontrolē, izstrādājot kopā ar komandām. Tie darbojas vienādi ar neatkarīgām vidēm vai koplietošanas izstrādes vidēm, lai gan ar koplietojamām vidēm eksportēšana un izgūšana dabiski ietver visas risinājuma izmaiņas, ne tikai tās, ko veicis izstrādātājs, kas veic eksportu. Līdzīgi, importējot risinājumu .zip failu, notiek dabiska darbība, lai pārrakstītu visus komponentus.

Risinājuma izveide

Šajā procedūrā tiek identificētas tipiskās darbības, kas tiek izmantotas, pirmo reizi izveidojot risinājumu.

1. Tīrā vidē izveidojiet Dataverse risinājumu un pēc tam pievienojiet vai izveidojiet komponentus, ja nepieciešams.

2. Kad esat gatavs reģistrēties, veiciet tālāk norādītās darbības.

   1. Nepārvaldīta risinājuma eksportēšana.

   2. Izmantojot risinājumu iepakotāja rīku, izvelciet risinājumu komponentu failos.

   3. No šiem izvilktajiem komponentu failiem avota vadīklai pievienojiet nepieciešamos failus.

   4. Iesniedziet šīs izmaiņas avota vadīklā.

Pārveidot risinājumu

Šī procedūra identificē tipiskos soļus, kas tiek lietoti, pārveidojot esošu risinājumu.

1. Sinhronizējiet vai iegūstiet jaunākos risinājuma komponentu failu avotus.

2. Izmantojot risinājumu iepakotāja rīku, iepakojiet komponentu failus nepārvaldītā risinājuma .zip failā.

3. Importējiet nepārvaldīto risinājuma failu vidē.

4. Pēc nepieciešamības pielāgojiet un rediģējiet risinājumu.

5. Kad esat gatavs pārbaudīt izmaiņas avota kontrolē, veiciet tālāk norādītās darbības.

   1. Nepārvaldīta risinājuma eksportēšana.

   2. Izmantojot rīku Solution Packager, izvelciet eksportēto risinājumu komponentu failos.

   3. Sinhronizējiet vai iegūstiet jaunākos avota vadīklas avotus.

   4. Saskaņojiet, ja pastāv kādi konflikti.

   5. Iesniedziet izmaiņas avota vadīklā.

   Pirms tālāku pielāgojumu izveides organizācijā ir jāveic 2. un 3. solis. 5. solī B solis ir jāpabeidz pirms C soļa.

Skatiet arī:

Risinājuma komponenta faila atsauce (SolutionPackager)
SolutionPackager rīks
Avota kontroles failu formāti