For den grenbaserede version skal vi tale om følgende diagram, som perfekt illustrerer panoramaet af konfigurationsstyringsprocessen. Først og fremmest er dette diagram skrevet ud fra Git-modellen, men faktisk har Git og Subversion fundet ud af konceptet versionskontrolstyring, men Git tager et kvalitativt spring fremad end Subversion, når det gælder branch management og distribueret ydeevne (men dette er ikke fokus i denne artikel).
Før vi introducerer princippet for denne graf, lad os tale om to forskellige strategier til generel versionskontrol: den ene er "pioneer backbone, stable branch", og den anden er "stable backbone, pioneer branch". Som navnet antyder, er det den stabile version (produktionsversion), på stammen eller på grenen. I tilfælde af traditionelle projektteams, der bruger VSS, er det svært at sige, hvilken tilstand det hører til, hovedsageligt fordi VSS selv ikke har en branch management-strategi, så mange projektteams etablerer to versioner (eller tre) versioner af biblioteker, svarende til produktionsmiljøet og udviklingsmiljøet, hvilket selvfølgelig også er en form for branch management i forklædning. Men hvis du skifter til Subversion eller Git som versionskontrolværktøj, bruger de fleste teams stable trunk-tilstanden, det vil sige, at trunken (truck eller master) svarer til et stabilt produktionsmiljø og tagger forskellige udgivelser for at angive produktionsversionen. Personligt mener jeg, at det stabile backbone-kodemønster bør være den absolutte mainstream versionsstyringsløsning for kodekontrol i øjeblikket. Billedet ovenfor er den standard "stabile rygrad"-styringsmodel.
mester: Den tilsvarende Subversion er lastbil。 I overensstemmelse med produktionsversionen tagges den én gang pr. udgivelse.
Release branch (også kendt som Integration Branch): Så længe produktionen opdateres, skal den først flettes ind i release-grenen (integrationsgrenen). Det minder lidt om det, projektteamet i øjeblikket kalder begrebet "præ-produktion" og "simuleret miljø".
Udvikl gren (udviklingsgren eller udviklingsgren): Miljøet, som udviklingsmiljøet står overfor.
Feature branch (feature branch): Nogle uafhængige funktioner kan adskilles fra en separat udviklingsgren. Dette er primært for at håndtere, at nogle funktioner kan tage relativt lang tid at opdatere, så udgivelsen og de adskilte grene ikke trækker ned.
Hotfixes-grenen (fejlrettelsesgren): Fejlen her er hovedsageligt en produktionsfejl.
Efter at have introduceret stammen og grenene, skal jeg introducere retningen for disse grenes dannelse og sammensmeltning.
Master er produktionsversionen, og stammen accepterer kun to grene til sammenflettning, den ene er release-grenen (integrationsgrenen) og den anden er hotfixes-grenen. Ingen anden gren kan fusioneres til en produktionsafdeling.
Udgivelsesgrenen oprettes oprindeligt samtidig med produktionen, hvilket er præcis det samme som produktionen. Han accepterer kun dev-grenen for at fusionere med den. Med andre ord accepterer han ikke sammenfletning direkte fra feature-grenen eller bugfix-grenen.
Udviklingsgrenen, udviklingsgrenen, ligesom integrationsgrenen, er den samme som produktionsmiljøet på et bestemt tidspunkt. Men efterhånden som udviklingen skrider frem, vil nye funktioner fortsat blive skabt på udviklingsafdelingen. Udviklingsteorien accepterer kun sammensmeltning af to grene, den ene er hotfixes og den anden er feature-grenen.
feature-grenen, startende på et bestemt punkt (version) med dev-grenen, vil feature-grenen til sidst fusionere med dev-grenen.
Lad os kort introducere versionskontrolmetoden i form af et scenarie
Antag, at en produktionsversion er opdelt i grene (dev, hotfixes, release), og på dette tidspunkt begynder dev at udvikle i alt ti funktioner. Da 8 af de 10 funktioner var udviklet, begyndte testteamet at gribe ind for intern testning, og konfigurationsadministratoren implementerede udviklingsgrenen i udviklingsmiljøet for test via kontinuerlige integrationsværktøjer (et separat emne her). Da testverifikationen viste, at to af funktionerne var helt uacceptable og skulle laves om, såsom simpel forsikringsforsikring og skadeanmeldelse, blev to funktionsgrene adskilt fra udviklingen, svarende til simpel forsikringsforsikring og skadesrefusion, og på udviklingsgrenen skulle den tilsvarende kode også rulles tilbage (manuel betjening her). Når testteamet finder ud af, at der ikke er noget problem med dev branch-testen, opfylder den betingelserne for UAT, så konfigurationsadministratoren sammenlægger dev-grenen med release-branchen og bruger derefter kontinuerlige integrationsværktøjer til at publicere denne branch til pre-produktionsmiljøet og overdrage den til brugeren til test. Når brugerverifikationen finder et problem, ændrer udvikleren dev-grenen og samler den derefter med release-grenen (her, på det oprindelige billede, er den direkte ændret i release-grenen, jeg synes ikke, det er godt, jeg anbefaler, at udvikleren kun tager sig af udviklingsgrenen), når verifikations-release-verifikationsprocessen pludselig opdager, at der er en alvorlig fejl i build-miljøet, som skal rettes med det samme, så bliver den hurtigt ændret på hotfixes-branchen, og den bliver hurtigt startet efter at have bekræftet, at den er korrekt. Samtidig bliver hotfixes-grenen slået sammen med dev (her er det mest manuelt, fordi produktionsversionen på dette tidspunkt allerede er meget forskellig fra dev-versionen, og det ofte er umuligt at gennemføre den automatiske sammensmeltning), og derefter bliver dev slået sammen med releasen. Efter en periode kan claim-return-funktionen ikke længere være nødvendig og skal annulleres, så claim return-funktionen vil blive slettet. En anden funktion er nem at forsikre og er blevet udviklet og igen integreret i udviklingsgrenen for at gå live med den næste onlineversion.
Ovenstående scenarie omfatter grundlæggende rutinemæssig udvikling, udpakning, nødopdateringer og andre scenarier i den daglige udviklingsproces.
|
Opslået på 08/04/2018 10.25.39
|
|
|
|
