Za različico, ki temelji na vejah, moramo govoriti o naslednjem diagramu, ki popolnoma prikazuje panoramo procesa upravljanja konfiguracije. Najprej, ta diagram je napisan na podlagi Git modela, vendar sta Git in Subversion dejansko odkrila koncept upravljanja nadzora različic, vendar Git naredi kvalitativni preskok v primerjavi s Subversion pri upravljanju vej in distribuirani zmogljivosti (vendar to ni osrednja tema tega članka).
Preden predstavimo načelo tega grafa, se pogovorimo o dveh različnih strategijah splošnega nadzora različic, ena je "pionirska hrbtenica, stabilna veja", druga pa "stabilna hrbtenica, pionirska veja". Kot že ime pove, gre za stabilno različico (produkcijsko različico), na deblu ali na veji. V primeru tradicionalnih projektnih ekip, ki uporabljajo VSS, je težko reči, kateremu načinu pripada, predvsem zato, ker VSS sam nima strategije upravljanja podružnic, zato številne projektne ekipe vzpostavijo dve (ali tri) knjižnici različic, ki ustrezajo produkcijskemu in razvojnemu okolju, seveda pa gre tudi za nekakšno upravljanje podružnic v prikriti obliki. Če pa preklopite na Subversion ali Git kot orodje za nadzor različic, večina ekip uporablja način stabilnega trunka, torej trunk (tovornjak ali glavni) ustreza stabilnemu produkcijskemu okolju in označuje različne izdaje za označevanje produkcijske različice. Osebno menim, da bi moral biti vzorec stabilne hrbtenice kode trenutno absolutna glavna rešitev za upravljanje različic kode. Zgornja slika prikazuje standardni model upravljanja "stabilne hrbtenice".
mojster: Ustrezni Subversion je tovornjak。 V skladu s produkcijsko različico je označen enkrat ob vsaki izdaji.
Release Branch (znan tudi kot integracijska veja): Dokler je produkcija posodobljena, jo je treba najprej združiti v vejo za izdajo (integracijsko vejo). To je nekoliko podobno temu, kar projektna ekipa trenutno imenuje koncept "predprodukcije" in "simuliranega okolja".
Razvijajoča veja (razvojna veja ali razvojna veja): Okolje, s katerim se sooča razvojno okolje.
Veja značilnosti (veja značilnosti): Nekatere neodvisne funkcije je mogoče ločiti od ločene razvojne veje. To je predvsem zato, da se spopade s tem, da nekatere funkcije lahko trajajo razmeroma dolgo za posodobitev, da ne bi zavlekli izdaje in ločenih vej.
Veja hitrih popravkov (veja za popravljanje hroščev): Napaka tukaj je predvsem produkcijska napaka.
Po uvedbi debla in vej moram predstaviti smer nastajanja in združevanja teh vej.
Master je produkcijska različica, trunk pa sprejema le dve veji za združevanje, ena je veja za izdajo (integracijska veja) in druga veja hotfixes. Nobena druga veja se ne more združiti v proizvodno vejo.
Veja izdaje se sprva ustvari istočasno kot produkcija, kar je povsem enako kot produkcija. Sprejme samo razvojno vejo za združitev z njo. Z drugimi besedami, ne sprejema neposrednega združevanja iz veje funkcij ali veje popravkov napak.
Razvojna veja, razvojna veja, tako kot integracijska veja, je enaka produkcijskemu okolju v določenem trenutku. Vendar pa se bodo med razvojem na razvojni veji še naprej ustvarjale nove funkcije. Razvojna teorija sprejema le združevanje dveh vej, ena so hotfixi, druga pa veja značilnosti.
Feature Branch se začne pri določeni točki (verziji) z razvojno vejo, feature branch se bo sčasoma združil z razvojno vejo.
Na kratko predstavimo metodo nadzora različic v obliki scenarija
Predpostavimo, da je produkcijska različica razdeljena na veje (razvoj, hotfixi, izdaja) in takrat razvijalec začne razvijati skupno deset funkcij. Ko je bilo razvitih 8 od 10 funkcij, je testna ekipa začela posegati v interno testiranje, konfiguracijski administrator pa je razvojno vejo namestil v razvojno okolje za testiranje preko orodij za neprekinjeno integracijo (to je tukaj ločena tema). Ko je testna verifikacija pokazala, da sta bili dve funkciji popolnoma nesprejemljivi in ju je bilo treba ponovno narediti, kot sta preprosto zavarovanje zavarovanja in vračilo zahtevkov, sta bili dve veji funkcij ločeni od razvoja, ki sta ustrezali preprostemu zavarovanju zavarovanja in vračilu zahtevkov, na razvojni veji pa je bilo treba ustrezno kodo prav tako povrniti nazaj (tukaj ročno upravljanje). Ko testna ekipa ugotovi, da ni težav s testom razvojne veje, ta izpolnjuje pogoje UAT, zato skrbnik konfiguracije združi razvojno vejo z release vejo in nato uporabi orodja za neprekinjeno integracijo, da to vejo objavi v predprodukcijsko okolje in jo preda uporabniku v testiranje. Ko preverjanje uporabnikov odkrije težavo, razvijalec spremeni razvojno vejo in jo nato združi z vejo za izdajo (tukaj, na izvirni sliki, je neposredno spremenjena v veji izdaje, mislim, da to ni dobro, priporočam, da razvijalec sodeluje le z razvojno vejo), ko postopek preverjanja izdaje nenadoma odkrije resno napako v gradbenem okolju, ki jo je treba takoj odpraviti, se ta napaka nujno spremeni na veji hotfixes in se nujno zažene po preverjanju pravilnosti. Hkrati se veja hotfixes združi z razvojem (tukaj je večinoma ročno, ker je produkcijska različica že zelo drugačna od razvojne in je pogosto nemogoče dokončati samodejno združitev), nato pa se razvoj združi v izdajo. Po določenem času funkcija vračila zahtevka morda ni več potrebna in jo je treba preklicati, zato bo veja funkcije vračila zahtevka izbrisana. Druga funkcija je enostavna za zavarovanje in je bila ponovno razvita ter združena z razvojno vejo, da bo zaživela z naslednjo spletno različico.
Zgornji scenarij v bistvu vključuje rutinsko razvijanje, razpakiranje, nujne posodobitve in druge scenarije v vsakodnevnem razvojnem procesu.
|
Objavljeno na 8. 04. 2018 10:25:39
|
|
|
|
