Voor de branch-gebaseerde versie moeten we het volgende diagram bespreken, dat perfect het panorama van het configuratiebeheerproces illustreert. Allereerst is dit diagram geschreven op basis van het Git-model, maar in feite hebben Git en Subversion het concept van versiebeheer doorgrond, maar Git maakt wel een kwalitatieve sprong vooruit dan Subversion in branch management en gedistribueerde prestaties (maar dit is niet het onderwerp van dit artikel).
Voordat we het principe van deze graaf introduceren, laten we het hebben over twee verschillende strategieën voor algemene versiebeheer: de ene is "pioneer backbone, stable branch" en de andere is "stable backbone, pioneer branch". Zoals de naam al doet vermoeden, is het de stabiele versie (productieversie), op de stam of op de tak. In het geval van traditionele projectteams die VSS gebruiken, is het moeilijk te zeggen tot welke modus het behoort, vooral omdat VSS zelf geen branch management-strategie heeft, dus veel projectteams zetten respectievelijk twee versiebibliotheken (of drie) op, overeenkomend met de productieomgeving en de ontwikkelomgeving; natuurlijk is dit ook een soort branch management in vermomming. Als je echter overschakelt naar Subversion of Git als versiebeheertool, gebruiken de meeste teams de stabiele trunkmodus, dat wil zeggen dat de trunk (truck of master) overeenkomt met een stabiele productieomgeving, en verschillende releases taggen om de productieversie aan te geven. Persoonlijk vind ik dat het stabiele backbone-codepatroon momenteel de absolute mainstream versiebeheeroplossing voor code zou moeten zijn. De bovenstaande afbeelding is het standaard "stabiele ruggengraat" managementmodel.
meester: De bijbehorende Subversion is truck。 Overeenkomstig met de productieversie wordt het één keer per release getagd.
Release branch (ook bekend als integratiebranch): Zolang de productie is bijgewerkt, moet deze eerst worden samengevoegd met de release-tak (integratie-branch). Het lijkt enigszins op wat het projectteam momenteel het concept van "pre-productie" en "gesimuleerde omgeving" noemt.
Develop branch (dev branch of dev branch): De omgeving waarmee de ontwikkelingsomgeving te maken heeft.
Feature branch (feature branch): Sommige onafhankelijke functies kunnen worden losgekoppeld van een aparte ontwikkelingsafdeling. Dit is vooral om te zorgen dat sommige functies relatief lang kunnen duren om te updaten, zodat de release en aparte vertakkingen niet worden vertraagd.
Hotfixes-tak (bugfix-branch): De bug hier is vooral een productiebug.
Na het introduceren van de stam en takken moet ik de richting van het ontstaan en samenvoegen van deze takken introduceren.
Master is de productieversie, en de trunk accepteert slechts twee vertakkingen voor samenvoeging: één is de release-tak (integratie-branch) en de andere is de hotfixes-branch. Geen enkele andere tak kan worden samengevoegd met een productievestiging.
De release-tak wordt aanvankelijk tegelijk met de productie aangemaakt, wat precies hetzelfde is als de productie. Hij accepteert alleen de dev-branch om ermee te fuseren. Met andere woorden, hij accepteert geen samenvoeging direct vanuit de feature-tak of de bugfixes-branch.
De ontwikkelafdeling, de ontwikkelingsafdeling, net als de integratieafdeling, is op een bepaald moment hetzelfde als de productieomgeving. Naarmate de ontwikkeling vordert, zullen er echter nieuwe functies blijven worden gecreëerd op de dev-afdeling. Dev Theory accepteert alleen het samensmelten van twee takken, één is hotfixes en de andere is de feature-tak.
feature-branch, beginnend op een bepaald punt (versie) met de dev-branch, zal de feature-branch uiteindelijk samensmelten met de dev-branch.
Laten we kort de versiebeheermethode introduceren in de vorm van een scenario
Stel dat een productieversie is opgedeeld in takken (dev, hotfixes, release), en op dat moment begint dev met het ontwikkelen van in totaal tien functies. Toen 8 van de 10 functies waren ontwikkeld, begon het testteam in te grijpen voor interne tests, en de configuratiebeheerder zette de dev branch uit naar de ontwikkelomgeving voor testen via continue integratietools (een apart onderwerp hier). Toen de testverificatie vaststelde dat twee functies volledig onacceptabel waren en opnieuw moesten worden gedaan, zoals eenvoudige verzekeringsverzekering en claimteruggave, werden twee feature-afdelingen gescheiden van de ontwikkelaars, die overeenkwamen met eenvoudige verzekeringsverzekering en schadevergoeding, en op de ontwikkelaarsafdeling moest de bijbehorende code ook worden teruggedraaid (hier handmatig bedienen). Wanneer het testteam ontdekt dat er geen probleem is met de dev branch-test, voldoet deze aan de voorwaarden van UAT, dus voegt de configuratiebeheerder de dev-branch samen met de release-branch en gebruikt continue integratietools om deze branch te publiceren in de pre-productieomgeving en aan de gebruiker over te dragen voor test. Wanneer de gebruikersverificatie een probleem vindt, wijzigt de ontwikkelaar de dev-branch en voegt deze vervolgens samen met de release-branch (hier, op de originele afbeelding, is deze direct aangepast in de release-branch, ik denk dat dit niet goed is, ik raad aan dat de ontwikkelaar alleen de dev-branch aanspreekt), wanneer het verificatieproces plotseling ontdekt dat er een ernstige bug in de build-omgeving is die onmiddellijk opgelost moet worden, wordt deze dringend aangepast in de hotfixes-branch en wordt deze snel gestart nadat de correctheid is bevestigd. Tegelijkertijd wordt de hotfixes-branch samengevoegd met dev (hier is het grotendeels handmatig, omdat de productieversie op dat moment al heel anders is dan de dev-versie, en het vaak onmogelijk is om de automatische merge te voltooien), waarna dev in de release wordt samengevoegd. Na een bepaalde periode kan de claim return-functie niet langer nodig zijn en moet deze worden geannuleerd, waardoor de claim return-feature branch wordt verwijderd. Een andere functie is eenvoudig te verzekeren en is ontwikkeld en opnieuw samengevoegd met de dev-tak om live te gaan met de volgende online versie.
Het bovenstaande scenario omvat in feite routinematige ontwikkeling, uitpakken, noodupdates en andere scenario's in het dagelijkse ontwikkelingsproces.
|
Geplaatst op 08-04-2018 10:25:39
|
|
|
|
