Harupõhise versiooni puhul peame rääkima järgmisest diagrammist, mis illustreerib suurepäraselt konfiguratsioonihaldusprotsessi panoraami. Esiteks on see diagramm kirjutatud Giti mudeli põhjal, kuid tegelikult on Git ja Subversion versioonihalduse kontseptsiooni välja töötanud, kuid Git teeb kvalitatiivse hüppe edasi võrreldes Subversioniga haruhalduses ja hajutatud jõudluses (kuid see ei ole selle artikli fookus).
Enne selle graafiku põhimõtte tutvustamist räägime kahest erinevast üldise versioonihalduse strateegiast: üks on "pioneer selgroog, stabiilne haru" ja teine "stabiilne selgroog, pioneerharu". Nagu nimigi ütleb, on see stabiilne versioon (tootmisversioon), kas trunkil või harul. Traditsiooniliste projektimeeskondade puhul, kes kasutavad VSS-i, on raske öelda, millisesse režiimi see kuulub, peamiselt seetõttu, et VSS-il endal puudub harude haldamise strateegia, mistõttu paljud projektimeeskonnad loovad vastavalt kaks (või kolm) versiooniteeki, mis vastavad tootmiskeskkonnale ja arenduskeskkonnale, muidugi on see ka haruhalduse vorm varjatult. Kui aga vahetad versioonihalduse tööriistana Subversioni või Giti vastu, kasutavad enamik meeskondi stabiilset pagasiruumi režiimi, st pagasiruum (veoauto või master) vastab stabiilsele tootmiskeskkonnale ja märgistab erinevad versioonid, et näidata tootmisversiooni. Isiklikult arvan, et stabiilne selgrookoodimuster peaks praegu olema absoluutne peavoolu koodi versioonihalduse lahendus. Ülalolev pilt on standardne "stabiilse selgroo" juhtimismudel.
meister: Vastav Subversion on veoauto。 Vastavalt tootmisversioonile märgistatakse see iga väljalaske kord.
Release Branch (tuntud ka kui integratsiooniharu): Kui tootmine on uuendatud, tuleb see esmalt ühendada väljalaskeharuga (integratsiooniharu). See on mõnevõrra sarnane sellele, mida projektimeeskond praegu nimetab "eeltootmise" ja "simuleeritud keskkonna" kontseptsiooniks.
Arenda haru (arendusharu või arendusharu): Keskkond, millega arenduskeskkond silmitsi seisab.
Feature haru (Feature haru): Mõningaid sõltumatuid funktsioone saab eraldada eraldi arendusharust. See on peamiselt selleks, et arvestada, et mõnede funktsioonide uuendamine võib võtta suhteliselt kaua aega, et mitte vähendada väljalaske ja harude eraldamist.
Kiirparanduste haru (veaparandusharu): Viga siin on peamiselt tootmisviga.
Pärast tüve ja harude tutvustamist pean tutvustama nende harude genereerimise ja ühendamise suunda.
Master on tootmisversioon ning trunk aktsepteerib ühendamiseks ainult kahte haru, üks on release branch (integratsiooniharu) ja teine hotfixes branch. Ühtegi teist haru ei saa ühendada tootmisharuks.
Väljalaskeharu luuakse algselt samal ajal kui tootmine, mis on täpselt sama mis tootmine. Ta aktsepteerib ainult arendajate haru, et sellega ühineda. Teisisõnu, ta ei aktsepteeri ühendamist otse funktsioonide harust ega veaparanduste harust.
Arendusharu, arendusharu, nagu ka integratsiooniharu, on sama mis tootmiskeskkond teatud ajahetkel. Kuid arenduse edenedes luuakse arendusharus jätkuvalt uusi funktsioone. Arendusteooria aktsepteerib ainult kahe haru ühendamist, üks on hotfixed ja teine feature branch.
funktsiooni haru, alates teatud punktist (versioonist) koos arendusharuga, ühineb funktsiooniharu lõpuks arendusharuga.
Tutvustame lühidalt versioonihalduse meetodit stsenaariumi kujul
Oletame, et tootmisversioon on jagatud harudeks (dev, hotfixes, release) ja sel ajal hakkab arendaja arendama kokku kümmet funktsiooni. Kui 10-st funktsioonist 8 olid välja töötatud, hakkas testitiim sekkuma sisemiseks testimiseks ning konfiguratsiooniadministraator juurutas arendusharu arenduskeskkonda testimiseks pideva integratsiooni tööriistade kaudu (siin eraldi teema). Kui testi kontroll näitas, et kaks funktsiooni on täiesti vastuvõetamatud ja vajavad ümbertegemist, nagu lihtne kindlustuskindlustus ja kahju tagastus, eraldati arendajast kaks funktsiooniharu, mis vastasid lihtsale kindlustuskindlustusele ja kahjunõude tagasimaksele, ning arendusharus tuli ka vastav kood tagasi kerida (käsitsi juhtimine siin). Kui testimeeskond leiab, et arendusharu testiga probleeme ei ole, vastab see UAT tingimustele, seega ühendab konfiguratsiooniadministraator arendusharu release haruga ning kasutab pideva integratsiooni tööriistu, et avaldada see haru eeltootmiskeskkonnas ja anda kasutajale testimiseks. Kui kasutaja verifitseerimine leiab probleemi, muudab arendaja arendusharu ja ühendab selle seejärel väljalaskeharuga (siin, originaalpildil, on see otseselt muudetud väljalaske harus, arvan, et see pole hea, soovitan arendajal vaadata ainult arendusharu), kui verifitseerimise väljalaske kontrolliprotsess avastab ootamatult tõsise vea, mis vajab kohest parandamist, siis muudetakse see kiiresti hotfixes harus ja käivitatakse kiiresti, kui on kinnitatud, et see on õige. Samal ajal liidetakse hotfixes haru arendusega (siin on see enamasti käsitsi, sest sel ajal on tootmisversioon juba väga erinev arendusversioonist ja automaatset ühendamist on sageli võimatu lõpule viia), ning seejärel liidetakse dev väljaandega. Mõne aja pärast võib nõuete tagastuse funktsiooni enam mitte vaja minna ja see tuleb tühistada, mistõttu kahju tagastuse funktsiooni haru kustutatakse. Teine funktsioon on lihtne kindlustada ja on arendatud ning liidetud arendusharuga, et käivitada järgmine veebiversioon.
Ülaltoodud stsenaarium hõlmab põhimõtteliselt rutiinset arendust, lahtipakkimist, hädaolukorra uuendusi ja muid stsenaariume igapäevases arendusprotsessis.
|
Postitatud 08.04.2018 10:25:39
|
|
|
|
