Für die branch-basierte Version müssen wir über das folgende Diagramm sprechen, das das Panorama des Konfigurationsmanagementprozesses perfekt veranschaulicht. Zunächst einmal basiert dieses Diagramm auf dem Git-Modell, aber tatsächlich haben Git und Subversion das Konzept des Versionskontrollmanagements herausgefunden, wobei Git einen qualitativen Fortschritt als Subversion in Sachen Branch-Management und verteilter Leistung macht (aber das ist nicht der Fokus dieses Artikels).
Bevor wir das Prinzip dieses Graphen einführen, sprechen wir über zwei verschiedene Strategien zur allgemeinen Versionskontrolle: Eine ist "Pioneer Backbone, stable branch" und die andere "stable backbone, pioneer branch". Wie der Name schon sagt, handelt es sich um die Stallversion (Produktionsversion), entweder am Stamm oder am Ast. Im Fall traditioneller Projektteams, die VSS verwenden, ist es schwierig zu sagen, zu welchem Modus es gehört, hauptsächlich weil VSS selbst keine Branch-Management-Strategie hat, sodass viele Projektteams jeweils zwei Versionsbibliotheken (oder drei) einrichten, entsprechend Produktionsumgebung und Entwicklungsumgebung; natürlich handelt es sich auch um eine Art Branch-Management im Verborgenen. Wenn man jedoch auf Subversion oder Git als Versionskontrollwerkzeug umsteigt, verwenden die meisten Teams den stabilen Trunk-Modus, das heißt, der Trunk (Truck oder Master) entspricht einer stabilen Produktionsumgebung und markiert verschiedene Versionen, um die Produktionsversion anzuzeigen. Persönlich denke ich, dass das stabile Backbone-Code-Muster derzeit die absolute gängige Lösung für Code-Versionskontrolle sein sollte. Das obige Bild zeigt das Standardmodell des "stabilen Rückgrats".
Meister: Die entsprechende Subversion ist LKW。 Entsprechend der Produktionsversion wird es einmal pro Veröffentlichung getaggt.
Release-Branch (auch bekannt als Integration Branch): Solange die Produktion aktualisiert ist, muss sie zuerst in den Release-Branch (Integrationszweig) eingegliedert werden. Es ähnelt in gewisser Weise dem, was das Projektteam derzeit als "Vorproduktion" und "simulierte Umgebung" bezeichnet.
Develop Branch (Dev Branch oder Dev Branch): Das Umfeld, dem die Entwicklungsumgebung gegenübersteht.
Merkmalszweig (Merkmalszweig): Einige unabhängige Funktionen können von einem separaten Entwicklungszweig getrennt werden. Dies dient hauptsächlich dazu, damit umzugehen, dass einige Features relativ lange zum Aktualisieren benötigen können, um den Release und die getrennten Verzweigungen nicht herunterzuziehen.
Hotfixes-Branch (Bugfix-Branch): Der Bug hier ist hauptsächlich ein Produktionsfehler.
Nachdem ich den Stamm und die Äste eingeführt habe, muss ich die Richtung der Entstehung und Verschmelzung dieser Äste vorstellen.
Master ist die Produktionsversion, und der Trunk akzeptiert nur zwei Zweige zum Zusammenführen, einer ist der Release-Branch (Integrations-Branch) und der andere der Hotfixes-Branch. Kein anderer Zweig kann in einen Produktionszweig eingegliedert werden.
Der Release-Zweig wird zunächst gleichzeitig mit der Produktion erstellt, was genau der Produktion entspricht. Er akzeptiert nur den Dev-Branch, um mit ihm zusammenzuführen. Mit anderen Worten: Er akzeptiert kein Zusammenführen direkt aus dem Feature-Branch oder dem Bugfixes-Zweig.
Der Entwicklungszweig, der Entwicklungszweig, ist wie der Integrationszweig zu einem bestimmten Zeitpunkt dasselbe wie die Produktionsumgebung. Im Verlauf der Entwicklung werden jedoch weiterhin neue Funktionen im Dev-Branch geschaffen. Die Entwicklungstheorie akzeptiert nur das Zusammenführen zweier Zweige, einer ist Hotfix, der andere der Feature-Zweig.
Feature-Branch, beginnend an einem bestimmten Punkt (Version) mit dem Dev-Branch, wird der Feature-Branch schließlich mit dem Dev-Branch verschmolzen.
Lassen Sie uns die Versionskontrollmethode kurz in Form eines Szenarios vorstellen
Angenommen, eine Produktionsversion ist in Zweige unterteilt (Entwicklung, Hotfixes, Veröffentlichung), und zu diesem Zeitpunkt beginnt die Entwicklung, insgesamt zehn Funktionen zu entwickeln. Als 8 der 10 Funktionen entwickelt wurden, begann das Testteam, für interne Tests einzugreifen, und der Konfigurationsadministrator stellte den Entwicklungszweig in die Entwicklungsumgebung für Tests über kontinuierliche Integrationstools bereit (hier ein separates Thema). Als die Testverifikation ergab, dass zwei der Funktionen völlig inakzeptabel waren und neu gemacht werden mussten, wie einfache Versicherungsversicherung und Schadensrückgabe, wurden zwei Feature-Zweige von der Entwicklung getrennt, die der einfachen Versicherungs- und Schadensrückerstattung entsprachen, und im Entwicklungsbereich musste auch der entsprechende Code zurückgesetzt werden (manueller Betrieb hier). Wenn das Testteam feststellt, dass es kein Problem mit dem Dev-Branch-Test gibt, erfüllt er die Bedingungen von UAT, sodass der Konfigurationsadministrator den Dev-Branch in den Release-Branch integriert und dann mit kontinuierlichen Integrationstools diesen Branch in der Pre-Production-Umgebung veröffentlicht und dem Benutzer zum Testen übergibt. Wenn die Benutzerverifizierung ein Problem findet, modifiziert der Entwickler den Dev-Branch und fügt ihn dann in den Release-Branch zusammen (hier, auf dem Originalbild, ist er direkt im Release-Branch modifiziert, ich halte das für nicht gut, ich empfehle, dass der Entwickler sich nur auf den Dev-Branch konzentriert). Wenn der Verifizierungs-Release-Verifizierungsprozess plötzlich entdeckt, dass es einen ernsthaften Fehler in der Build-Umgebung gibt, der sofort behoben werden muss, wird er dringend im Hotfixes-Branch geändert und nach Überprüfung der Korrektheit sofort gestartet. Gleichzeitig wird der Hotfixes-Zweig mit Dev zusammengeführt (hier ist es größtenteils manuell, da die Produktionsversion zu diesem Zeitpunkt bereits sehr anders ist als die Dev-Version und es oft unmöglich ist, die automatische Zusammenführung abzuschließen), und dann wird Dev in die Version integriert. Nach einer gewissen Zeit kann die Claim-Return-Funktion möglicherweise nicht mehr benötigt werden und muss abgebrochen werden, sodass die Claim Return-Funktions-Branch gelöscht wird. Eine weitere Funktion ist einfach zu versichern und wurde entwickelt und wieder in den Entwicklerzweig integriert, um mit der nächsten Online-Version live zu gehen.
Das oben genannte Szenario umfasst im Wesentlichen routinemäßige Entwicklung, Auspacken, Notfallupdates und weitere Szenarien im täglichen Entwicklungsprozess.
|
Veröffentlicht am 08.04.2018 10:25:39
|
|
|
|
