Erweiterte Branching- und Merging-Strategien (Teil 1 von 2)

Mendix
21. Oktober 2016
Minute gelesen

In dieser zweiteiligen Blogserie beschreibe ich erweiterte Branching- und Merging-Strategien für komplexe Betriebsumgebungen. Diese Strategien basieren auf meiner persönlichen Erfahrung bei aktuellen und früheren Kunden mit mehreren Projekten und parallel laufender Wartung.

Im ersten Teil werde ich eine kurze Beschreibung einer grundlegenden Strategie geben, da ich davon ausgehe, dass die meisten Leute diese verwenden. Es ist die Standardstrategie für Mendix Projekte und basiert direkt auf früheren Mendix Blogs und die Dokumentation zu Versionskontrollkonzepten. Anschließend werde ich eine Version erweiterter Strategien für das Verzweigen und Zusammenführen erläutern, die dem Prinzip „Kein Müll im Stamm“ folgt. Eine zweite Strategie wird im nächsten Blog vorgestellt.

Ich gehe davon aus, dass die Leser über ein gutes Verständnis der Grundlagen von Branching und Merging, Subversion (SVN) und Mendix, wie im beschrieben Mendix Dokumentation zu Versionskontrollkonzepten. Ich werde jedoch kurz erklären, wie Verzweigungen und Zusammenführungen im Modellierer durchgeführt werden.

Grundlegende Strategie (Standard): Mit der Hauptlinie

Diese grundlegende Strategie wird in den meisten Mendix Projekte, da dies der Standardausgangspunkt für jedes Projekt ist. Dieser Ansatz wird häufig fortgesetzt, wenn das Projekt größer geworden ist und bereits live ist. Bei dieser Strategie wird die Main Line für fast jede Art von Entwicklung verwendet: Alle Änderungen werden in die Main Line übernommen und Bereitstellungen werden nur mithilfe der Main Line durchgeführt. Änderungen werden nacheinander übernommen, normalerweise vermischt und Fehlerbehebungen werden erneut darüber übernommen. Infolgedessen können Änderungen nur als „Paketangebot“ geliefert werden – alles oder nichts.

Sobald eine Version bereitgestellt wurde, sind die Optionen zum Korrigieren einer fehlerhaften Bereitstellung begrenzt. Beispielsweise 1) Zurückkehren zu einem vorherigen Modellpaket, 2) Zurücksetzen der letzten Commits (und Verlust Ihrer Arbeit) und Generieren eines neuen Pakets oder 3) Fortsetzen der Entwicklung und Korrigieren des fehlerhaften Teils. Letztere Option wird meiner Erfahrung nach bisher am häufigsten gewählt. Beachten Sie, dass ein Rollback der letzten Commits an sich eine riskante Option ist, nach der das Testen und Übernehmen des neuen Modells noch erforderlich ist.

Ein allgemeiner, gut gemeinter Ratschlag: Geben Sie diese Grundstrategie so schnell wie möglich auf. Zum Beispiel, sobald eine stabile Version in einer der Testumgebungen bereitgestellt wird, oder spätestens, wenn die erste Version in der Produktionsumgebung veröffentlicht wird. Zu Recht fragen Sie sich natürlich: Was ist die Alternative? Was kann man besser machen? Wo besteht Verbesserungsbedarf?

Zuallererst sollten Sie das Prinzip übernehmen: „Kein Gerümpel im Kofferraum.„Im Allgemeinen bedeutet das:

ALLE Entwicklungen finden in Zweigstellen statt (und NIEMALS auf der Hauptstrecke)
Die Hauptstrecke ist der allgemeine Ausgangspunkt für neue Zweigstrecken
Nur vollständig getestete Änderungen werden in die Hauptlinie integriert
Nach einer Zusammenführung mit der Hauptlinie ist eine Zusammenführung mit allen aktiven Zweigen erforderlich. Außerdem ist eine Zusammenführung mit dem Quellzweig erforderlich, wenn die Entwicklung auf dem Zweig fortgesetzt wird. Dies ist erforderlich, um sicherzustellen, dass alle Zweige synchron bleiben.

Strategie für Instandhaltung und Projekte

Die Anwendung des Prinzips „Kein Müll im Kofferraum“ führt uns zu Strategie 1: einer Strategie für parallele Wartung und Projekte. In dieser Strategie können die folgenden Zweige unterschieden werden:

Hauptstrecke
Ein kontinuierlicher Wartungszweig, beispielsweise genannt Wartung or Business As Usual (BAU)
Optional ein Projekt Branch oder Feature-Branch für größere Änderungen
Zusätzlich kann es Hotfix-Zweige für einen kleinen Produktionspatch geben

Bei dieser Strategie werden Änderungen nur an den Zweigen vorgenommen: hauptsächlich in der Wartung und Projekt Zweige. Die Bereitstellung in einer Testumgebung erfolgt auf einem Paket, das aus dem jeweiligen Zweig generiert wird. Nach erfolgreichem Abschluss des Tests werden die Änderungen in die Hauptlinie integriert. Danach müssen die Commits wieder in alle aktiven Zweige integriert werden, damit alles synchron bleibt. Eine Produktionsbereitstellung erfolgt aus einem versionierten Paket der Hauptlinie und manchmal aus einer getesteten Hotfix-Linie.

In der Abbildung unten finden Sie eine visuelle Darstellung der Hauptaktivitäten dieser Strategie. Die Zeit läuft von links nach rechts. Die drei Zweige werden als horizontale Linien angezeigt: der Wartungszweig, die Hauptlinie und ein Projektzweig. Jede festgeschriebene Änderung an einem Zweig wird als Kreis auf dieser Linie dargestellt. Zwei Änderungsreihen wurden an der Wartungszweiglinie vorgenommen und festgeschrieben (1 und 2). Diese Änderungen werden zunächst mit einem Bereitstellungspaket getestet, das direkt aus dieser Linie generiert wird. Nachdem alle Tests abgeschlossen und akzeptiert wurden, werden die Änderungen mit der Hauptlinie zusammengeführt. In der Abbildung werden die Zusammenführungen als Pfeile angezeigt. Nach der Zusammenführung werden die Änderungen festgeschrieben (3) und dann mit der Projektzweiglinie zusammengeführt (4). Schließlich werden die Änderungen, die bei Nummer 3 festgeschrieben wurden, wieder mit der Wartungszweiglinie zusammengeführt (5), um sicherzustellen, dass alle Linien synchronisiert sind.

Diagramm zum Verzweigen und Zusammenführen von Projekten

Wie funktioniert das Verzweigen und Zusammenführen im Mendix Schimmel

Um Zweige verwenden zu können, muss bei jedem Projekt der Team Server aktiviert sein. Am einfachsten geht das, indem Sie ein Projekt mit Team Server starten. Tun Sie es einfach, es ist sowieso kostenlos. Alternativ können Sie dies auch zu einem späteren Zeitpunkt mit der Option Auf Team-Server hochladen… in England, Team Menü.

Verzweigung

Für die Wartungslinie muss eine einmalige Einrichtung durchgeführt werden. Neue Zweige für Projekte werden benötigt, wenn Projekte kommen und gehen. Vergessen Sie nicht, die alten Projektzweige zu bereinigen. Möglicherweise benötigen Sie auch einen neuen Zweig für die Funktionsentwicklung oder Hotfixes. Zweige können über die Menüoption Nebenstrecken verwalten… von der Team Menüpunkt.

Im Falle einer neuen Zweiglinie für Wartung oder Projekte sollte der gewählte Ursprung im Allgemeinen die neueste Version der Hauptlinie sein. Im Falle eines Feature- oder Hotfix-Zweiges hängt es davon ab, wofür er gedacht ist. Ein solcher Zweig könnte für sich allein stehen oder ein Unterzweig von Wartung oder Projekten sein.

In jedem Fall muss jede Zweiglinie ihre Änderungen und zumindest die Wartung und das Projekt bereitstellen. Zweiglinien müssen auch synchron bleiben, und hier kommt das Zusammenführen ins Spiel. Manchmal bestehen Feature-Zweiglinien über einen längeren Zeitraum, und Sie müssen sie möglicherweise ebenfalls synchron halten. Wenn Sie die Zweiglinien nicht synchronisieren, treten früher oder später komplizierte Versionskonflikte auf.

Vereinigung

Das Zusammenführen erfolgt mit dem Änderungen hier zusammenführen… Option in der Team Menü. Die sofortige Konfrontation mit drei Optionen kann zunächst einschüchternd wirken. Lesen Sie jedoch sorgfältig (eigentlich können Sie hier nichts falsch machen, da die ungültigen Optionen deaktiviert werden).

Fenster zusammenführen

Das Zusammenführen von Änderungen aus einer Zweiglinie in die Hauptlinie aus dem Projekt- oder Wartungszweig kann häufig mithilfe des Port-Fix or Feature-Zweig zusammenführen Optionen. Mit dem Einen Fix portieren Option können Sie immer noch eine oder mehrere Revisionen zusammenführen. Die Port-Feature-Zweig Die Option lässt dies nicht zu und führt alle Revisionen zusammen, die zuvor nicht zusammengeführt wurden.

Port-Fix Fenster

Port-Feature-Zweig Fenster

Wenn Sie den Modellierer mit einer geöffneten Zweiglinie verwenden, stehen Ihnen die ersten beiden Optionen nicht zur Verfügung. Es bleiben nur die Erweiterte Zusammenführung Option. Dort müssen Sie die Zweiglinie auswählen, von der aus zusammengeführt werden soll, sowie die Start- und Endrevision, die in die Zusammenführung einbezogen werden sollen. Die Auswahl der Revisionen ist sehr nützlich, da Sie bei einer Zusammenführung nicht unbedingt alles einbeziehen möchten.

Beachten Sie abschließend, dass alle Zusammenführungen (und alle anderen Subversion-Aktionen) im Tortoise SVN-Client für Windows durchgeführt werden können. Tortoise SVN erleichtert außerdem die Wiedereingliederung oder Rückzusammenführung mit einer speziellen Option. Beachten Sie, dass nicht alle Versionen mit dem Mendix SVN-Setup. Überprüfen Sie die Mendix Referenzhandbuch für die richtige Version, wenn Sie Tortoise verwenden möchten.

Persönlich mache ich alle Verzweigungen und Zusammenführungen am liebsten im Mendix Modeler. Ich habe Tortoise installiert, weil die Icons im Windows Explorer sichtbar sind, sodass ich den Status eines Projektordners direkt sehen kann. Außerdem bietet Tortoise einen Dateibetrachter, der über das Mendix Modellierer, mit dem Sie verschiedene (widersprüchliche) Versionen von Java-Dateien vergleichen können, was sich in einigen Fällen als sehr nützlich erwiesen hat.

Fazit

Was sind also meine bisherigen Erfahrungen mit dieser Strategie? Ich muss sagen, dass sie gut funktioniert und ein guter Schritt nach vorne ist, um die Kontrolle über Änderungen und Versionen zu behalten. Es ist ein gutes Modell, es ist einfach und liefert, was benötigt wird. Allerdings bringt diese Strategie im Laufe der Zeit eine Reihe von Herausforderungen mit sich:

In einem Entwicklungszweig können sich Änderungen an Funktionen und Fehlerbehebungen häufen und zu einem Alles-oder-Nichts-Paket führen (mehr dazu im nächsten Blog).
Das Kombinieren von Zweigen für die Bereitstellung in einer Testumgebung mit Änderungen sowohl aus einem Projekt als auch aus den Wartungszweiglinien ist schwierig und manchmal unmöglich (wenn viele Konflikte auftreten).

Lassen Sie uns abschließend die Anwendbarkeit dieser Strategien und die Erfahrungen, die wir in der Zeit, in der wir sie verwendet haben, gemacht haben, überprüfen. Die obige Strategie ist in den folgenden Situationen nützlich:

Wenn Sie den Aufwand für Wartung und Projekte trennen möchten
Für Releases mit mehreren Features und Fixes, die separat entwickelt werden sollen
Für Änderungspfade mit hohem und niedrigem Risiko

Das abschließende Urteil für die vorgestellte Strategie lautet, dass es sich um ein gutes Modell handelt. Es funktioniert in der Praxis gut und ist verständlich. Wir haben diese Strategie über ein Jahr lang erfolgreich eingesetzt, bis wir aufgrund ihrer Einschränkungen auf ernsthafte Probleme stießen. Mehr dazu im zweiten Teil dieses Blogs.

Lesen Sie hier Teil 2

Vielen Dank

Danke an Richard, der den Grundstein gelegt und mich dazu gebracht hat, über die Verbesserung von Verzweigungen und Zusammenführungen nachzudenken, und mich auch dazu gedrängt hat, mich weiter zu verbessern. Danke an Reinout, meine Sogeti-Kollegen Edzo und Louis und die Mendix Gutachter für ihre konstruktiven Kommentare. Ohne sie wäre das Endergebnis nicht dasselbe gewesen.

Über David de Groot

David arbeitet jetzt bei Sogeti und hat mit Mendix seit vielen Jahren und ist ein zertifizierter Advanced Developer. Er hat bei verschiedenen niederländischen und internationalen Unternehmen gearbeitet, hauptsächlich als Berater in den Bereichen Wartung und Support, war aber zeitweise auch an Projekten und neuen Builds beteiligt. David hat einen Hintergrund in der Oracle- und PL/SQL-Entwicklung und besitzt einen Master of Science-Abschluss in Künstlicher Intelligenz.