For den grenbaserte versjonen må vi snakke om følgende diagram, som perfekt illustrerer panoramaet av konfigurasjonsstyringsprosessen. Først og fremst er dette diagrammet skrevet basert på Git-modellen, men faktisk har Git og Subversion funnet ut av konseptet for versjonskontrolladministrasjon, men Git tar et kvalitativt sprang fremover enn Subversion når det gjelder grenhåndtering og distribuert ytelse (men dette er ikke fokus i denne artikkelen).
Før vi introduserer prinsippet for denne grafen, la oss snakke om to forskjellige strategier for generell versjonskontroll, den ene er «pioneer backbone, stable branch», og den andre er «stable backbone, pioneer branch». Som navnet antyder, er det den stabile versjonen (produksjonsversjonen), på stammen eller på grenen. I tilfellet med tradisjonelle prosjektteam som bruker VSS, er det vanskelig å si hvilken modus det tilhører, hovedsakelig fordi VSS selv ikke har en branch management-strategi, så mange prosjektteam etablerer to versjonsbiblioteker (eller tre) henholdsvis, tilsvarende produksjonsmiljøet og utviklingsmiljøet, og dette er selvfølgelig også en form for forkledd branch management. Men hvis du bytter til Subversion eller Git som et versjonskontrollverktøy, bruker de fleste lag stabil trunk-modus, det vil si at trunken (truck eller master) tilsvarer et stabilt produksjonsmiljø, og tagger forskjellige versjoner for å indikere produksjonsversjonen. Personlig mener jeg at det stabile ryggradskodemønsteret bør være den absolutt mainstream versjonskontrollløsningen for kodekontroll i dag. Bildet ovenfor er den standard «stabile ryggrad»-styringsmodellen.
mester: Den tilsvarende Subversjonen er lastebil。 I samsvar med produksjonsversjonen tagges den én gang per utgivelse.
Release branch (også kjent som integrasjonsgren): Så lenge produksjonen er oppdatert, må den først slås sammen med release-grenen (integrasjonsgrenen). Det ligner noe på det prosjektteamet i dag kaller konseptet «pre-produksjon» og «simulert miljø».
Utvikle gren (utviklingsgren eller utviklingsgren): Miljøet utviklingsmiljøet står overfor.
Funksjonsgren (funksjonsgren): Noen uavhengige funksjoner kan skilles fra en egen utviklingsgren. Dette er hovedsakelig for å håndtere det faktum at noen funksjoner kan ta relativt lang tid å oppdatere, slik at ikke utgivelsen og separate grener trekkes ned.
Hotfixes-gren (feilrettingsgren): Feilen her er hovedsakelig en produksjonsfeil.
Etter å ha introdusert stammen og grenene, må jeg introdusere retningen for dannelse og sammensmelting av disse grenene.
Master er produksjonsversjonen, og stammen aksepterer kun to grener for sammenslåing, én er release-grenen (integrasjonsgrenen) og den andre er hotfixes-grenen. Ingen annen gren kan slås sammen med en produksjonsgren.
Release-grenen opprettes opprinnelig samtidig med produksjonen, noe som er nøyaktig det samme som produksjon. Han godtar bare dev-grenen for å slå seg sammen med den. Med andre ord, han godtar ikke sammenslåing direkte fra feature-grenen eller bugfixes-grenen.
Utviklingsgrenen, utviklingsgrenen, som integrasjonsgrenen, er den samme som produksjonsmiljøet på et bestemt tidspunkt. Men etter hvert som utviklingen skrider frem, vil nye funksjoner fortsette å bli laget på utviklingsgrenen. Dev Theory aksepterer kun sammenslåing av to grener, den ene er hotfixes og den andre er feature-grenen.
Feature branch, fra et bestemt punkt (versjon) med dev branch, vil feature branch etter hvert slå seg sammen med dev branch.
La oss kort introdusere versjonskontrollmetoden i form av et scenario
Anta at en produksjonsversjon er delt inn i grener (utvikling, hotfixes, utgivelse), og på dette tidspunktet begynner utviklingen å utvikle totalt ti funksjoner. Da 8 av de 10 funksjonene var utviklet, begynte testteamet å gripe inn for intern testing, og konfigurasjonsadministratoren distribuerte utviklingsgrenen til utviklingsmiljøet for testing gjennom kontinuerlige integrasjonsverktøy (et eget tema her). Da testverifiseringen fant at to av funksjonene var helt uakseptable og måtte gjøres om, som enkel forsikringsforsikring og skaderetur, ble to funksjonsgrener skilt fra utviklingen, tilsvarende enkel forsikringsforsikring og skaderefusjon, og på utviklingsgrenen måtte også den tilsvarende koden rulles tilbake (manuell drift her). Når testteamet finner ut at det ikke er noe problem med dev branch-testen, oppfyller den betingelsene for UAT, så konfigurasjonsadministratoren slår sammen dev-branch med release-branchen, og bruker deretter kontinuerlige integrasjonsverktøy for å publisere denne branch til pre-produksjonsmiljøet og overlevere den til brukeren for testing. Når brukerverifiseringen finner et problem, endrer utvikleren utviklingsgrenen, og slår den deretter sammen med release-grenen (her, på det opprinnelige bildet, er den direkte modifisert i release-grenen, jeg synes ikke dette er bra, jeg anbefaler at utvikleren kun bruker utviklergrenen), når verifiseringsprosessen for release-verifisering plutselig oppdager at det er en alvorlig feil i byggemiljøet som må fikses umiddelbart, blir den raskt endret på hotfixes-grenen, og den startes raskt etter å ha verifisert at den er korrekt. Samtidig slås hotfixes-grenen sammen med dev (her er det for det meste manuelt, fordi produksjonsversjonen allerede er veldig forskjellig fra dev-versjonen, og det ofte er umulig å fullføre den automatiske sammenslåingen), og deretter blir dev slått sammen med utgivelsen. Etter en periode kan det hende at kravreturfunksjonen ikke lenger er nødvendig og må kanselleres, så kravretur-funksjonen vil bli slettet. En annen funksjon er enkel å sikre og har blitt utviklet og slått sammen med utvikleravdelingen igjen for å gå live med neste nettversjon.
Scenariet ovenfor inkluderer i hovedsak rutinemessig utvikling, utpakking, nødoppdateringer og andre scenarier i den daglige utviklingsprosessen.
|
Publisert på 08.04.2018 10:25:39
|
|
|
|
