Tag Archives: Git

Vor vielen Jahren verwendete Trello Android eine ziemlich einfache Git-Branching-Strategie – zumindest dachten wir das damals.

Wir wären voll entwickelt hauptsächlich Verwendung von Auszahlungsanträgen. hauptsächlich Es ist so konzipiert, dass es immer freigegeben werden kann, obwohl wir gelegentlich eine erstellen würden Freigabe / xyz Verzweigungen, wenn wir bedenken, dass einige Funktionen zusätzliche Zeit zum Testen benötigen.

Nachdem Atlassian uns übernommen hatte, stießen wir auf einige Probleme mit unserem Prozess.

Erstens ist Atlassian ein börsennotiertes Unternehmen und muss sich daher daran halten Sarbanes-Oxley-Act (SOX). Für uns bedeutete dies, dass wir die Release-Zweige mit SOX kompatibel machen mussten, wobei zusätzliche Regeln und Einschränkungen eingehalten werden mussten. Das Erstellen eines neuen Zweigs, der mit SOX kompatibel ist, verursachte eine Menge zusätzlicher Kosten, und das Löschen eines Zweigs war noch ekelhafter. Also, Die Filialen der Edition waren nun ein riesiges PITA zu erstellen und zu löschen.

Auch, Unsere alte Strategie neigte dazu, beim Beheben von Fehlern alptraumhafte Situationen zu schaffen. Angenommen, wir bereiten uns vor Ausgabe / 1.3.0aber es stellte sich heraus Version / 1.2.0 hatte einen schweren Fehler. Wir würden das beheben Notkorrektur / 1.2.1oh, aber wie man sicherstellt, dass die Fehlerbehebung erfolgreich war hauptsächlich ich Ausgabe / 1.3.0, scheiße, lass uns alles aufheben. Hoffen wir, dass der Hotfix keine zusätzlichen Hotfixes erfordert oder Dinge erledigt werden Ja wirklich hässlich.

(Ich habe versucht, ein Diagramm zu erstellen, das das Obige demonstriert, aber es war so ein Witz, dass ich Ihnen das alles erspart habe.)

Mit anderen Worten, die „einfache“ Lösung wurde angesichts leider alltäglicher Umstände ziemlich komplex und es fehlte eine klar definierte Strategie. Dieses Problem wurde durch das wachsende Team verschärft; Der Kommunikationsaufwand darüber, wo Code verbunden werden soll, wächst exponentiell mit der Anzahl der Entwickler.

Vor diesem Hintergrund haben wir uns auf die Suche nach einer besseren Verzweigungsstrategie gemacht.

Ich glaube nicht an eine Lösung für alle, und das gilt insbesondere für Code-Management-Strategien. Ihr Kontext, Ihre Ziele und Einschränkungen führen Sie zum richtigen Business-Tool.

Beispielsweise, GitHub-Flow Es ist großartig! Der einzige gemeinsame Zweig ist hauptsächlich, kombinieren Sie Funktionen über eine Auszahlungsanforderung und bam – setzen Sie sofort. Es ist fantastisch einfach! Aber GitHub Flow setzt auf kontinuierliche Implementierung, und Android-Apps können das nicht.

Daher haben wir für unseren ersten Schritt eine Liste mit Faktoren erstellt, die es zu berücksichtigen gilt.

Hier sind die Probleme, die wir zu lösen versuchten:

• Das Erstellen eines SOX-kompatiblen Zweigs ist teuer.
• Wir brauchen eine klar definierte Strategie für alle Situationen.
• Unsere Strategie sollte auf mehr als ein paar Entwickler zugeschnitten sein.

Anschließend haben wir die kulturellen Vorlieben des Teams aufgelistet:

• Wir überprüfen den Code vor dem Zusammenführen.
• Wir vermeiden lang andauernde Feature Branches (statt Feature Flags zu verwenden).
• Wir wollen das Release vor Auslieferung in unserer eigenen Filiale testen/reparieren können.

Zum Schluss noch ein paar Fakten zu unserer Umwelt:

• Wir veröffentlichen regelmäßig drei Versionen: intern, Beta und Produktion.
• Wir geben jeweils nur eine Version der Software für die Produktion frei; wir sollten niemals alte vererbte Editionen pflegen.
• Android unterstützt keine kontinuierliche Bereitstellung.

Letztendlich haben wir darauf unsere Verzweigungsstrategie aufgebaut Dreifluss. Die Grundidee des Dreiklangs besteht darin, nur drei langlebige, stabile Zweige zu haben – einen für die Entwicklung, Kandidaten für die Veröffentlichung und Veröffentlichungen.

Unsere drei Filialen sind hauptsächlich, Kandidatich Lass los. hauptsächlich steht für kontinuierliche Weiterentwicklung. Wenn Sie eine neue Beta starten möchten, verbinden Sie sich hauptsächlich hinein Kandidat. Wenn diese Konstruktion stabil genug ist, verbinden Sie sich Kandidat hinein Lass los.

Wenn ein Fehler gefunden wird in Kandidatdann repariere es Kandidat und schließen Sie es wieder an hauptsächlich. Auch wenn ein schwerwiegender Fehler in gefunden wird Lass los und Sie müssen eine dringende Korrektur vornehmen, beheben Sie es Lass losund verbinden Sie dann dieses Update mit Kandidat und dann hauptsächlich.

(Beachten Sie, dass es niemals Verbindungen direkt von gibt hauptsächlich zu Lass los oder umgekehrt; Vorteil vergeht immer Kandidat bedeutet Einfachheit und Konsistenz, dass IMO die zusätzliche Arbeit wert ist.)

Wann immer Sie Code in einen der drei Zweige (hauptsächlich, Kandidat, Lass los) erstellen Sie einen eigenen Merkmalszweig (z. dlew / Funktion) und öffnen Sie eine Auszahlungsanforderung im Zielzweig.

Wir verwenden Feature-Labels, um zu vermeiden, dass Code bereitgestellt wird, bevor er an Benutzer ausgegeben wird. Das halbfertige Feature kann noch kombiniert werden Kandidat ich Lass losnur im deaktivierten Zustand.

Unsere Probleme wurden auf drei Arten behoben:

• Stabile Branches bedeuten, dass Sie nie wieder einen SOX-kompatiblen Branch erstellen oder löschen müssen.
• Jeder stabile Zweig kann auf unseren internen, Beta- oder Produktionsversionen veröffentlicht werden.
• Wir haben ein Handbuch für die Entwicklung von Funktionen, das Lösen von Beta-Problemen und das Einrichten von Hotfixes.
• Es ist eine einfache Strategie, die es einfach macht zu wissen, wo der Code zu verbinden ist (hauptsächlich für Entwickler, Kandidat für beta, Lass los für dringende Reparaturen).

Es ist auch mit unseren bestehenden Einstellungen kompatibel:

• Wir können immer noch Auszahlungsanträge verwenden, um den Code zu überprüfen.
• Es enthält explizit Feature-Flags und vermeidet lang andauernde Feature-Zweige.
• Es gibt uns Zeit, einen Kandidaten für die Veröffentlichung zu backen, bevor wir ihn in Produktion nehmen.

Als Bonus fügt Three-Stream auch keinen zusätzlichen Speicherplatz hinzu, den wir nicht benötigen. Die Abschaffung der Unterstützung für Dinge wie kontinuierliche Implementierung und Legacy-Releases reduziert die Komplexität.

Der springende Punkt der Triade ist, dass Sie drei stabile Zweige haben, aber die Art und Weise, wie Sie diese drei Zweige verwalten, kann von Team zu Team variieren. Es ist daher erwähnenswert, dass wir uns getrennt haben originaler Artikel In zwei Wegen:

• Kurzlebige Zweige – Wir sind große Fans von Code-Reviews, daher ist das Öffnen von Pull-Requests in Verzweigungen ein wichtiger Teil unseres Ablaufs. Remote-Zweige sind eine Voraussetzung für PR, aber der ursprüngliche Artikel diskutiert jede Art von Gräueltaten des Remote-Zweigs. Sie schlagen vor, einfach alle Verpflichtungen auf den Master zu verlagern – aber wie überprüft man dann den Code?

  Jetzt haben wir Nein Verwenden Sie langlebige Funktionszweige – wir stimmen zu, dass dies Albträume sind, die darauf warten, passiert zu werden, und dass Funktionsflags überlegen sind.

• Zusammenführen zwischen Zweigen – Der Artikel verwendet Schubkraft für Lass los Ast. Während dies Ihre Git-Bäume schöner aussehen lässt, schreiben wir den Git-Verlauf nicht gerne um (und die Einhaltung von SOX hindert uns sowieso daran, den Verlauf umzuschreiben).

  Es gibt eine gewisse Eleganz, immer zwischen den drei Zweigen zu verschmelzen; Es ist immer derselbe Vorgang, von einem zum anderen zu wechseln, und macht die Codehistorie vollständig nachvollziehbar. Darüber hinaus bedeutet die Verwendung von Merge, dass Sie nur Drag-Requests verwenden können, um zwischen Zweigen zusammenzuführen – ohne sich mehrere Git-Befehle merken zu müssen.

Wir haben andere beliebte Git-Branching-Strategien aus verschiedenen Gründen ausgeschlossen:

• Hüllenbasierte Entwicklung (auch bekannt als Stabile Hauptleitung oder Kaktus) – Diese Strategie war im Grunde das, was wir vorher gemacht haben.
• GitFlow – Es ist viel komplexer als andere Branching-Strategien und erfordert die Erstellung vieler Branch-Editionen.
• OneFlow – Einfacher als GitFlow, erfordert aber immer noch das Erstellen vieler Zweige der Version.
• GitHub-Flow – Für den Betrieb ist eine kontinuierliche Abgabe erforderlich.

Ich schlage nicht vor, dass heute jeder rausgeht und das Stativ benutzt. Aufgrund unserer Einschränkungen ist es großartig für uns, aber es funktioniert möglicherweise nicht für alle. Insbesondere gibt es mindestens zwei Fälle, in denen Sie das unbedingt tun sollten Nein benutze es:

• Wenn Sie eine kontinuierliche Bereitstellung durchführen können, verwenden Sie GitHub Flow. Es ist einfacher!
• Wenn Sie mehrere Releases gleichzeitig unterstützen müssen (Legacy-Versionen + aktuelle Version), funktioniert Tri-Flow einfach nicht.

Mit Ausnahme dieser Fälle würde ich in Betracht ziehen, Tri-Flow eine Chance zu geben. Wir verwenden es seit über zwei Jahren ohne Probleme.