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.

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 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 Microsoft Dataverse organizācijās.

3. Izstrādātājs A pielāgo "Aktīvo kontaktu" sistēmas skatu un Kontakta entītijas galveno formu.

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āpārbauda viens fails Kontakta galvenajai veidlapai un viens fails skatam “Aktīvie kontakti”.

   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īvie kontakti", kamēr izstrādātājs A to 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īvie kontakti" un kontaktu 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āpārbauda viens fails Kontakta galvenajai veidlapai un viens fails skatam “Aktīvie kontakti”.

   2. Izstrādātājam B būs jāpārbauda viens fails Konta galvenajai veidlapai un viens fails skatam “Aktīvie kontakti”.

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. Ir konflikts, jo "Aktīvo kontaktu" fails 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