Filialo versijai turime kalbėti apie šią schemą, kuri puikiai iliustruoja konfigūracijos valdymo proceso panoramą. Visų pirma, ši diagrama parašyta remiantis "Git" modeliu, tačiau iš tikrųjų "Git" ir "Subversion" išsiaiškino versijų valdymo koncepciją, tačiau "Git" daro kokybinį šuolį į priekį nei "Subversion" filialų valdymo ir paskirstyto našumo srityje (tačiau tai nėra šio straipsnio akcentas).
Prieš pristatydami šio grafiko principą, pakalbėkime apie dvi skirtingas bendro versijų valdymo strategijas, viena yra "pionierių stuburas, stabili šaka", o kita - "stabilus stuburas, pionierių šaka". Kaip rodo pavadinimas, tai yra stabili versija (gamybinė versija), ant bagažinės arba ant šakos. Tradicinių projektų komandų, naudojančių VSS, atveju sunku pasakyti, kuriam režimui jis priklauso, daugiausia dėl to, kad pats VSS neturi filialo valdymo strategijos, todėl daugelis projektų komandų sukuria atitinkamai dvi versijų bibliotekas (arba tris), atitinkančias gamybos aplinką ir kūrimo aplinką, žinoma, tai taip pat yra savotiškas užmaskuotas filialo valdymas. Tačiau jei perjungiate į Subversion arba Git kaip versijų valdymo įrankį, dauguma komandų naudoja stabilų bagažinės režimą, tai yra, bagažinė (sunkvežimis ar kapitonas) atitinka stabilią gamybos aplinką ir pažymi skirtingus leidimus, kad nurodytų gamybos versiją. Asmeniškai manau, kad stabilus kodo modelis šiuo metu turėtų būti absoliutus pagrindinis kodo versijų valdymo sprendimas. Aukščiau pateiktas paveikslėlis yra standartinis "stabilaus stuburo" valdymo modelis.
master: Atitinkama Subversion yra sunkvežimis。 Atitinkanti gamybinę versiją, ji žymima kartą per laidą.
Išleidimo šaka (taip pat žinoma kaip integracijos šaka): Kol gamyba atnaujinama, pirmiausia ją reikia sujungti į leidimo šaką (integracijos šaką). Tai šiek tiek panašu į tai, ką projekto komanda šiuo metu vadina "išankstinės gamybos" ir "imituojamos aplinkos" sąvokomis.
plėtoti šaką (kūrėjo šaka arba kūrėjo šaka): aplinka, su kuria susiduria kūrimo aplinka.
funkcijos šaka (feature branch): Kai kurias nepriklausomas funkcijas galima atskirti nuo atskiros plėtros šakos. Tai daugiausia susiję su tuo, kad kai kurių funkcijų atnaujinimas gali užtrukti gana ilgai, kad nebūtų nutemptas leidimas ir atskiros šakos.
Karštųjų pataisų šaka (klaidų taisymo šaka): Klaida čia daugiausia yra gamybos klaida.
Pristačius kamieną ir šakas, turiu pristatyti šių šakų generavimo ir sujungimo kryptį.
Pagrindinis yra gamybos versija, o magistralė priima tik dvi šakas sujungimui, viena yra išleidimo šaka (integracijos šaka), o kita yra karštųjų pataisų šaka. Jokia kita šaka negali būti sujungta į gamybos šaką.
Išleidimo šaka iš pradžių sukuriama tuo pačiu metu kaip ir gamyba, o tai yra lygiai tas pats, kas gamyba. Jis priima tik kūrėjo šaką, kad su ja susijungtų. Kitaip tariant, jis nepriima sujungimo tiesiogiai iš funkcijų šakos ar klaidų pataisymų šakos.
Kūrėjo šaka, kūrimo šaka, kaip ir integracijos šaka, tam tikru momentu yra tokia pati kaip gamybos aplinka. Tačiau tobulėjant kūrėjų šakoje ir toliau bus kuriamos naujos funkcijos. Dev teorija priima tik dviejų šakų sujungimą, viena yra karštosios pataisos, o kita yra funkcijų šaka.
funkcijos šaka, pradedant tam tikru momentu (versija) su kūrėjo šaka, funkcijos šaka galiausiai susijungs su kūrėjo šaka.
Trumpai pristatykime versijų valdymo metodą scenarijaus forma
Tarkime, kad gamybos versija yra padalinta į šakas (kūrėjas, karštosios pataisos, leidimas), ir šiuo metu kūrėjas pradeda kurti iš viso dešimt funkcijų. Kai buvo sukurtos 8 iš 10 funkcijų, testavimo komanda pradėjo įsikišti į vidinį testavimą, o konfigūracijos administratorius įdiegė kūrėjo šaką kūrėjo aplinkoje, kad būtų galima testuoti naudojant nuolatinio integravimo įrankius (atskira tema čia). Kai bandymo patikrinimas nustatė, kad dvi funkcijos buvo visiškai nepriimtinos ir jas reikėjo perdaryti, pvz., paprastas draudimo draudimas ir žalos grąžinimas, dvi funkcijų šakos buvo atskirtos nuo dev, atitinkančios paprastą draudimo draudimą ir žalos grąžinimą, o dev šakoje atitinkamą kodą taip pat reikėjo atšaukti (rankinis valdymas čia). Kai testavimo komanda nustato, kad nėra problemų dėl kūrėjo šakos testavimo, ji atitinka UAT sąlygas, todėl konfigūracijos administratorius sujungia kūrėjo šaką su leidimo šaka, o tada naudoja nuolatinio integravimo įrankius, kad paskelbtų šią šaką ikigamybinėje aplinkoje ir perduotų vartotojui testuoti. Kai vartotojo patvirtinimas randa problemą, kūrėjas modifikuoja kūrėjo šaką, o tada sujungia ją su leidimo šaka (čia, originaliame paveikslėlyje, ji tiesiogiai modifikuojama išleidimo šakoje, manau, kad tai nėra gerai, rekomenduoju kūrėjui susidurti tik su kūrėjo šaka), kai patvirtinimo leidimo tikrinimo procesas staiga nustato, kad kūrimo aplinkoje yra rimta klaida, kurią reikia nedelsiant ištaisyti, tada ji skubiai modifikuojama karštųjų pataisų šakoje ir skubiai paleidžiama patikrinus, ar ji teisinga. Tuo pačiu metu karštųjų pataisų šaka sujungiama su dev (čia ji dažniausiai yra rankinė, nes šiuo metu gamybinė versija jau labai skiriasi nuo dev versijos, ir dažnai neįmanoma užbaigti automatinio sujungimo), o tada dev sujungiamas į leidimą. Praėjus tam tikram laikui, pretenzijų grąžinimo funkcija gali būti nebereikalinga ir ją reikia atšaukti, todėl pretenzijų grąžinimo funkcijos šaka bus panaikinta. Kitą funkciją lengva apdrausti, ji buvo sukurta ir vėl sujungta į kūrėjo šaką, kad būtų galima pradėti naudoti kitą internetinę versiją.
Aukščiau pateiktas scenarijus iš esmės apima įprastą kūrimą, išpakavimą, avarinius atnaujinimus ir kitus scenarijus kasdieniame kūrimo procese.
|
Paskelbta 2018-04-08 10:25:39
|
|
|
|
