Filiāles versijai mums jārunā par šādu diagrammu, kas lieliski ilustrē konfigurācijas pārvaldības procesa panorāmu. Pirmkārt, šī diagramma ir uzrakstīta, pamatojoties uz Git modeli, bet patiesībā Git un Subversion ir izdomājuši versiju kontroles pārvaldības koncepciju, bet Git veic kvalitatīvu lēcienu uz priekšu nekā Subversion filiāļu pārvaldībā un sadalītajā veiktspējā (bet tas nav šī raksta uzmanības centrā).
Pirms šī grafika principa ieviešanas runāsim par divām dažādām vispārējās versiju kontroles stratēģijām, viena ir "pionieru mugurkauls, stabila filiāle", bet otra ir "stabils mugurkauls, pionieru filiāle". Kā norāda nosaukums, tā ir stabila versija (ražošanas versija), uz stumbra vai filiāles. Tradicionālo projektu komandu gadījumā, kas izmanto VSS, ir grūti pateikt, kuram režīmam tas pieder, galvenokārt tāpēc, ka VSS pašam nav filiāles vadības stratēģijas, tāpēc daudzas projektu komandas izveido attiecīgi divas versiju bibliotēkas (vai trīs), kas atbilst ražošanas videi un attīstības videi, protams, tas ir arī sava veida filiāles vadība. Tomēr, ja pārslēdzaties uz Subversion vai Git kā versiju kontroles rīku, lielākā daļa komandu izmanto stabilu bagāžnieka režīmu, tas ir, bagāžnieks (kravas automašīna vai kapteinis) atbilst stabilai ražošanas videi un atzīmē dažādus laidienus, lai norādītu ražošanas versiju. Personīgi es domāju, ka stabilam mugurkaula koda modelim šobrīd vajadzētu būt absolūtam mainstream koda versiju kontroles pārvaldības risinājumam. Iepriekš minētais attēls ir standarta "stabila mugurkaula" pārvaldības modelis.
master: Atbilstošais Subversion ir kravas automašīna。 Atbilstoši ražošanas versijai, tas tiek atzīmēts reizi katrā laidienā.
Laidiena filiāle (pazīstama arī kā integrācijas filiāle): kamēr produkcija tiek atjaunināta, tā vispirms ir jāapvieno laidiena filiālē (integrācijas filiālē). Tas ir nedaudz līdzīgs tam, ko projekta komanda pašlaik sauc par jēdzienu "pirmsražošana" un "simulēta vide".
Attīstīt filiāli (izstrādātāja filiāle vai izstrādātāja filiāle): vide, ar ko saskaras attīstības vide.
funkciju filiāle (feature branch): Dažas neatkarīgas funkcijas var atdalīt no atsevišķas attīstības nozares. Tas galvenokārt attiecas uz to, ka dažu funkciju atjaunināšana var aizņemt salīdzinoši ilgu laiku, lai nevilktu izlaišanu un atsevišķas filiāles.
labojumfailu filiāle (kļūdu labošanas filiāle): Kļūda šeit galvenokārt ir ražošanas kļūda.
Pēc stumbra un zaru ieviešanas man ir jāievieš šo zaru ģenerēšanas un apvienošanas virziens.
Master ir ražošanas versija, un Trunk pieņem tikai divas filiāles apvienošanai, viena ir izlaišanas filiāle (integrācijas filiāle) un otra ir labojumfailu filiāle. Nevienu citu nozari nevar apvienot ražošanas nozarē.
Izlaišanas filiāle sākotnēji tiek izveidota vienlaicīgi ar ražošanu, kas ir tieši tāda pati kā ražošana. Viņš pieņem tikai izstrādātāja filiāli, lai ar to apvienotos. Citiem vārdiem sakot, viņš nepieņem apvienošanu tieši no funkciju filiāles vai kļūdu labojumu filiāles.
Izstrādātāja filiāle, izstrādes filiāle, tāpat kā integrācijas filiāle, ir tāda pati kā ražošanas vide noteiktā brīdī. Tomēr, attīstoties attīstībai, izstrādātāja filiālē turpinās tikt izveidotas jaunas funkcijas. Izstrādātāju teorija pieņem tikai divu filiāļu apvienošanu, viena ir labojumfaili, bet otra ir funkciju filiāle.
Funkciju filiāle, sākot no noteikta punkta (versijas) ar izstrādātāja filiāli, funkcijas filiāle galu galā apvienosies ar izstrādātāja filiāli.
Īsumā iepazīstināsim ar versiju kontroles metodi scenārija veidā
Pieņemsim, ka ražošanas versija ir sadalīta filiālēs (dev, labojumfaili, izlaidums), un šobrīd izstrādātājs sāk izstrādāt kopumā desmit funkcijas. Kad tika izstrādātas 8 no 10 funkcijām, testēšanas komanda sāka iejaukties iekšējā testēšanā, un konfigurācijas administrators izvietoja izstrādātāja filiāli izstrādātāja vidē testēšanai, izmantojot nepārtrauktas integrācijas rīkus (atsevišķa tēma šeit). Kad testa pārbaudē tika konstatēts, ka divas funkcijas ir pilnīgi nepieņemamas un ir jāpārtaisa, piemēram, vienkārša apdrošināšanas apdrošināšana un prasību atgriešana, divas funkciju filiāles tika atdalītas no dev, kas atbilst vienkāršai apdrošināšanas apdrošināšanai un prasību atmaksai, un izstrādātāja filiālē atbilstošais kods arī bija jāatgriež (manuāla darbība šeit). Kad testēšanas komanda konstatē, ka nav problēmu ar izstrādātāja filiāles testu, tā atbilst UAT nosacījumiem, tāpēc konfigurācijas administrators apvieno izstrādātāja filiāli laidiena filiālē un pēc tam izmanto nepārtrauktas integrācijas rīkus, lai publicētu šo filiāli pirmsražošanas vidē un nodotu lietotājam testēšanai. Kad lietotāja verifikācija atrod problēmu, izstrādātājs modificē izstrādātāja filiāli un pēc tam apvieno to izlaišanas filiālē (šeit, sākotnējā attēlā, tas ir tieši modificēts izlaišanas filiālē, es domāju, ka tas nav labi, es iesaku izstrādātājam saskarties tikai ar izstrādātāja filiāli), kad verifikācijas izlaišanas pārbaudes process pēkšņi atklāj, ka būvēšanas vidē ir nopietna kļūda, kas nekavējoties jānovērš, tad tas tiek steidzami modificēts labojumfailu filiālē, un tas tiek steidzami uzsākts pēc tam, kad ir pārbaudīts, vai tas ir pareizs. Tajā pašā laikā labojumfailu filiāle tiek apvienota ar dev (šeit tā galvenokārt ir manuāla, jo šobrīd ražošanas versija jau ir ļoti atšķirīga no izstrādātāja versijas, un bieži vien nav iespējams pabeigt automātisko apvienošanu), un pēc tam dev tiek apvienots izlaidumā. Pēc kāda laika pieprasījuma atgriešanas funkcija var vairs nebūt nepieciešama un ir jāatceļ, tāpēc pretenziju atgriešanas funkcijas filiāle tiks dzēsta. Vēl viena funkcija ir viegli apdrošināma, un tā ir izstrādāta un atkal apvienota izstrādātāja filiālē, lai sāktu darboties ar nākamo tiešsaistes versiju.
Iepriekš minētais scenārijs būtībā ietver ikdienas izstrādi, izsaiņošanu, ārkārtas atjauninājumus un citus scenārijus ikdienas izstrādes procesā.
|
Publicēts 08.04.2018 10:25:39
|
|
|
|
