För den grenbaserade versionen behöver vi prata om följande diagram, som perfekt illustrerar panoramat av konfigurationshanteringsprocessen. För det första är detta diagram skrivet baserat på Git-modellen, men i själva verket har Git och Subversion listat ut konceptet versionskontrollhantering, men Git gör ett kvalitativt framsteg jämfört med Subversion när det gäller grenhantering och distribuerad prestanda (men detta är inte fokus för denna artikel).
Innan vi introducerar principen för denna graf, låt oss prata om två olika strategier för allmän versionskontroll, den ena är "pioneer backbone, stable branch" och den andra är "stable backbone, pioneer branch". Som namnet antyder är det den stabila versionen (produktionsversionen), på stammen eller på grenen. I fallet med traditionella projektteam som använder VSS är det svårt att säga vilket läge det tillhör, främst eftersom VSS självt inte har någon branch management-strategi, så många projektteam etablerar två versionsbibliotek (eller tre) respektive, motsvarande produktionsmiljö och utvecklingsmiljö, och detta är förstås också en form av branch management i förklädnad. Men om du byter till Subversion eller Git som versionshanteringsverktyg använder de flesta lag stabilt trunkläge, det vill säga bagageutrymmet (lastbil eller master) motsvarar en stabil produktionsmiljö och taggar olika versioner för att ange produktionsversionen. Personligen tycker jag att det stabila backbone-kodmönstret borde vara den absoluta mainstream-lösningen för versionshanteringshantering just nu. Bilden ovan är den standardiserade "stabila ryggraden"-hanteringsmodellen.
mästare: Den motsvarande Subversion är lastbil。 Motsvarande produktionsversionen taggas den en gång per utgåva.
Release-gren (även känd som integrationsgren): Så länge produktionen uppdateras måste den först sammanfogas med release-grenen (integrationsgrenen). Det liknar något det som projektteamet för närvarande kallar begreppen "förproduktion" och "simulerad miljö".
Utveckla gren (utvecklingsgren eller utvecklingsgren): Miljön som utvecklingsmiljön står inför.
Funktionsgren (funktionsgren): Vissa oberoende funktioner kan separeras från en separat utvecklingsgren. Detta är främst för att hantera att vissa funktioner kan ta relativt lång tid att uppdatera, för att inte dra ner release- och separata grenar.
Hotfixes-gren (buggfix-gren): Buggen här är främst en produktionsbugg.
Efter att ha introducerat stammen och grenarna behöver jag presentera riktningen för dessa grenars generering och sammanfogning.
Master är produktionsversionen, och trunken accepterar endast två grenar för sammanslagning, en är releasegrenen (integrationsgrenen) och den andra är hotfixes-grenen. Ingen annan gren kan slås samman med en produktionsgren.
Release-grenen skapas initialt samtidigt som produktionen, vilket är exakt samma som produktionen. Han accepterar bara dev-grenen för att slå ihop med den. Med andra ord accepterar han inte att man slås ihop direkt från funktionsgrenen eller bugfix-grenen.
Utvecklingsgrenen, utvecklingsgrenen, liksom integrationsgrenen, är samma som produktionsmiljön vid en viss tidpunkt. Men i takt med att utvecklingen fortskrider kommer nya funktioner att fortsätta skapas på utvecklingsavdelningen. Utvecklingsteorin accepterar bara sammanslagning av två grenar, en är hotfixes och den andra är funktionsgrenen.
Feature branch, från en viss punkt (version) med dev branch kommer feature branch så småningom att slås ihop med dev branch.
Låt oss kort introducera versionshanteringsmetoden i form av ett scenario
Anta att en produktionsversion är uppdelad i grenar (dev, hotfixes, release), och vid denna tidpunkt börjar dev utveckla totalt tio funktioner. När 8 av de 10 funktionerna utvecklades började testteamet ingripa för intern testning, och konfigurationsadministratören distribuerade utvecklingsgrenen till utvecklingsmiljön för testning via kontinuerliga integrationsverktyg (ett separat ämne här). När testverifieringen visade att två av funktionerna var helt oacceptabla och behövde göras om, såsom enkel försäkringsförsäkring och skadeanmälan, separerades två funktionsgrenar från utvecklingen, motsvarande enkel försäkringsförsäkring och skadeersättning, och på utvecklingsgrenen behövde motsvarande kod också rullas tillbaka (manuell hantering här). När testteamet upptäcker att det inte finns något problem med dev branch-testet uppfyller det villkoren för UAT, så konfigurationsadministratören slår ihop dev-grenen med release-grenen och använder sedan kontinuerliga integrationsverktyg för att publicera denna branch till förproduktionsmiljön och lämna över den till användaren för testning. När användarverifieringen hittar ett problem modifierar utvecklaren dev-grenen och slår sedan ihop den med release-grenen (här, på originalbilden, är den direkt modifierad i release-grenen, jag tycker inte detta är bra, jag rekommenderar att utvecklaren bara tar sig an utvecklar-grenen), när verifieringsprocessen för releaseverifiering plötsligt upptäcker att det finns en allvarlig bugg i byggmiljön som måste åtgärdas omedelbart, då ändras den akut på hotfixes-grenen och startas snabbt efter att ha verifierat att den är korrekt. Samtidigt slås hotfixes-grenen ihop med dev (här är det mestadels manuellt, eftersom produktionsversionen redan är mycket annorlunda än dev-versionen, och det ofta är omöjligt att slutföra den automatiska sammanslagningen), och sedan slås dev ihop med releasen. Efter en viss tid kan funktionen för claim return inte längre behövas och måste avbrytas, så branch claim return-funktionen kommer att tas bort. En annan funktion är lätt att försäkra och har utvecklats och slagits ihop med utvecklargrenen igen för att gå live med nästa onlineversion.
Ovanstående scenario inkluderar i princip rutinmässig utveckling, uppackning, nöduppdateringar och andra scenarier i den dagliga utvecklingsprocessen.
|
Publicerad på 2018-04-08 10:25:39
|
|
|
|
