Führt mein Unternehmen Filialen falsch zusammen?

28

Kürzlich bin ich auf einen MSDN-Artikel über das Verzweigen und Zusammenführen und SCM gestoßen : Branching and Merging Primer - Chris Birmele .

In dem Artikel heißt es, 'Big Bang Merge' ist ein zusammenlaufendes Gegenmuster:

Big Bang Merge - Verzögert das Zusammenführen von Zweigen bis zum Ende des Entwicklungsaufwands und versucht, alle Zweige gleichzeitig zusammenzuführen.

Mir ist aufgefallen, dass dies sehr ähnlich zu dem ist, was mein Unternehmen mit allen produzierten Entwicklungszweigen macht.

Ich arbeite in einem sehr kleinen Unternehmen mit einer Person, die als endgültige Überprüfungs- und Zusammenführungsbehörde fungiert. Wir haben 5 Entwickler (einschließlich mir), jeder von uns erhält eine eigene Aufgabe / einen eigenen Fehler / ein eigenes Projekt und wir verzweigen jeden Zweig vom aktuellen Trunk (Subversion) und führen dann die Entwicklungsarbeiten in unserem Zweig durch, testen die Ergebnisse, schreiben die Dokumentation Führen Sie bei Bedarf eine Peer-Review- und Feedback-Schleife mit den anderen Entwicklern durch und senden Sie die Filiale zur Überprüfung und Zusammenführung in unserer Projektmanagement-Software.

Mein Chef, der alleinige Verantwortliche für das Trunk-Repository, wird tatsächlich alle Überprüfungen von Zweigen auf einen bestimmten Zeitpunkt verschieben, an dem er so viele Überprüfungen wie möglich durchführt. Einige Zweige werden für Verbesserungen / Korrekturen zurückgeworfen, andere Zweige verschmelzen direkt mit dem Stamm, einige Zweige werden aufgrund von Konflikten usw. zurückgeworfen.

Es ist nicht ungewöhnlich, dass sich 10 bis 20 aktive Zweigstellen in der Warteschlange für die endgültige Überprüfung befinden, um in Trunk zusammengeführt zu werden.

Außerdem müssen Konflikte in der abschließenden Überprüfung und Zusammenführung häufig behoben werden, da zwei Zweige aus demselben Stamm erstellt wurden, aber denselben Code geändert haben. In der Regel vermeiden wir dies, indem wir einfach den Stamm umverzweigen und unsere Änderungen erneut anwenden und die Konflikte lösen und dann den neuen Zweig zur Überprüfung einreichen (Wiedergutmachung durch schlechte Besetzung).

Einige direkte Fragen, die ich habe, sind:

  • Zeigen wir genau das Anti-Pattern, das als "Big Bang Merge" bezeichnet wurde?
  • Sind einige der Probleme auf diesen Zusammenführungsprozess zurückzuführen?
  • Wie können wir diesen Zusammenführungsprozess verbessern, ohne den Engpass bei meinem Chef zu vergrößern?

Bearbeiten: Ich bezweifle, dass mein Chef seinen Griff um die Stammablage lockern oder anderen Entwicklern erlauben wird, sich zum Stamm zusammenzuschließen. Ich bin mir nicht sicher, was seine Gründe dafür sind, aber ich habe nicht wirklich vor, das Thema zur Sprache zu bringen, da es schon früher angesprochen und ziemlich schnell abgeschossen wurde. Ich denke, sie vertrauen uns einfach nicht, was keinen Sinn ergibt, weil sowieso alles verfolgt wird.

Jeder andere Einblick in diese Situation wäre willkommen.

user6567423
quelle
2
Warum wird das Zusammenführen verschoben? Normalerweise gibt es einen Grund, dies nicht sofort zu tun. Ist der einzelne Mann überarbeitet und der Rückstand wird einfach so groß? Gibt es einen anderen Grund, warum das Zusammenführen nicht rechtzeitig erfolgt?
Polygnom
1
Ich war mehrere Male in einer ähnlichen Position wie Sie. Ich kann aus eigener Erfahrung sagen, dass viele Unternehmen die Versionskontrolle, insbesondere die Verzweigung, fürchterlich falsch machen.
MechMK1
3
Was passiert, wenn der Chef in den Urlaub fährt?
Liath
Wie würden Sie die Verzweigungs- / Zusammenführungsstrategie für den Linux-Kernel definieren?
Braiam
Müssen die aufgrund von Konflikten zurückgeworfenen Änderungen, aber keine anderen Mängel, den Genehmigungsprozess erneut durchlaufen, sobald die Konflikte gelöst sind, oder werden sie als "vorläufig genehmigt" betrachtet?
Gregory Nisbet

Antworten:

60

Einige Vorschläge:

  • Es ist nichts Falsches daran, viele Feature- oder Bugfix-Zweige zu haben, solange die in jedem Zweig vorgenommenen Änderungen klein genug sind, dass Sie die resultierenden Zusammenführungskonflikte auf effektive Weise behandeln können. Das sollte Ihr Kriterium sein, wenn Ihre Arbeitsweise in Ordnung ist, nicht irgendein MSDN-Artikel.

  • Immer wenn ein Zweig in den Trunk eingebunden wird, sollte der Trunk so schnell wie möglich in alle offenen Entwicklungszweige eingebunden werden. Dies würde es allen Mitarbeitern im Team ermöglichen, Zusammenführungskonflikte parallel in ihrer eigenen Niederlassung zu lösen und so den Gatekeeper des Trunks zu entlasten.

  • Dies würde viel besser funktionieren, wenn der Gatekeeper nicht warten würde, bis 10 Zweige "zum Zusammenführen in den Trunk bereit" sind - das Lösen von Zusammenführungskonflikten aus den letzten Trunk-Integrationen benötigt immer etwas Zeit für das Team, daher ist es wahrscheinlich besser, in verwobenen Zeitintervallen zu arbeiten - eine Integration durch den Gatekeeper, eine erneute Zusammenführung durch das Team, die nächste Integration durch den Gatekeeper, die nächste erneute Zusammenführung durch das Team und so weiter.

  • Um Zweige klein zu halten, kann es hilfreich sein, größere Features in mehrere kleinere Aufgaben zu unterteilen und jede dieser Aufgaben in einem eigenen Zweig zu entwickeln. Wenn das Feature nicht produktionsbereit ist, bis alle Unteraufgaben implementiert sind, verbergen Sie es hinter einem Feature-Umschalter, bis alle Unteraufgaben abgeschlossen sind.

  • Früher oder später werden Sie auf Refactoring-Aufgaben stoßen, die sich auf viele Dateien in der Codebasis auswirken - diese haben ein hohes Risiko, dass Zusammenführungskonflikte mit vielen Zweigen auftreten. Diese können am besten gehandhabt werden, indem sie im Team klar kommuniziert werden und genau so gehandhabt werden, wie ich es oben geschrieben habe: indem sie vor der Reintegration in alle Entwicklungszweige integriert und in kleinere Sub-Refactorings aufgeteilt werden.

  • Für Ihre aktuelle Teamgröße funktioniert möglicherweise immer noch ein einzelner Gatekeeper. Wenn Ihr Team jedoch größer wird, führt kein Weg an einem zweiten (oder mehreren) Gatekeeper vorbei. Beachten Sie, dass ich nicht vorschlage, jedem zu erlauben, in den Kofferraum zu gelangen, aber das bedeutet nicht, dass nur Ihr Chef dazu in der Lage ist. Es gibt wahrscheinlich ein oder zwei hochrangige Entwickler, die ebenfalls Kandidaten für die Arbeit des Gatekeepers sein könnten. Und selbst für die Größe Ihres aktuellen Teams könnte ein zweiter Gatekeeper es Ihrem Team erleichtern, sich häufiger und früher in den Kofferraum zu integrieren, oder wenn Ihr Chef nicht verfügbar ist.

Doc Brown
quelle
2
Ich denke, Sie haben hier den besten Kommentar, wenn Sie anerkennen, dass wir den Stamm nicht einfach für alle öffnen können und dass unser Zweigstapel nicht immer ein Problem darstellt (nur wenn Konflikte auftreten). Ich denke, Sie haben gute Arbeit geleistet, um darauf hinzuweisen, wie wir Konflikte reduzieren und einen reibungslosen Zusammenführungszyklus gewährleisten können. Ich denke auch, dass Sie völlig richtig liegen, wenn Sie sagen, dass wir möglicherweise einen anderen Gatekeeper benötigen. Vielen Dank für diesen Einblick!
user6567423
@ user6567423 Möglicherweise möchten Sie auch Verzweigungen für jede Entwicklungsversion (z. B. 5.2.3 oder was auch immer) erstellen, von denen jeder Entwickler für Feature-Arbeiten abzweigen und diese dann zusammenführen kann und die dann wieder in die Hauptversion eingefügt werden können Lassen Sie den Zweig vom Chef frei, wenn die Entwicklung abgeschlossen ist.
nick012000
@ nick012000: Würde es dem Gatekeeper nicht schwerer machen, einzelne Feature-Zweige für / gegen die Integration in den Trunk zu akzeptieren oder abzulehnen? Ich meine, wenn mehrere Features in einen Entwicklungszweig gemischt werden, würde es sehr schwierig werden , diese Änderungen teilweise wieder in den Stamm zu integrieren. Oder vermisse ich etwas?
Doc Brown
10
" Lösen Sie parallele Zusammenführungskonflikte in Ihrem eigenen Zweig, und entlasten Sie den Gatekeeper des Stamms. " "Es ist besser für die Firma, ABER AUCH einfacher für Sie " scheint das Hauptverkaufsargument zu sein, wenn man dies dem Chef vorschlägt. Das geht eher in die Richtung Büropolitik, um die es bei SE nicht geht - aber in dieser Situation wird ohne die Zustimmung des Chefs alles andere in dieser technisch hervorragenden Antwort einfach nicht passieren.
R. Schmitz
@DocBrown Ja, aber es würde auch bedeuten, dass Sie viel weniger Konflikte zwischen den Entwicklungszweigen haben würden, und es würde Ihnen trotzdem das Maß an Sicherheit geben, das Sie erhalten, wenn Sie nicht direkt auf den Hauptzweig verschmelzen - und das kann er einfach lehnen Sie es ab, die Arbeit als erledigt zu akzeptieren und führen Sie die Zusammenführung durch, bis er mit dem Zustand des Codes insgesamt zufrieden ist.
nick012000
18

Zeigen wir genau das Anti-Pattern, das als "Big Bang Merge" bezeichnet wurde?

Klingt wie es.

Sind einige der Probleme auf diesen Zusammenführungsprozess zurückzuführen?

Bestimmt

Wie können wir diesen Zusammenführungsprozess verbessern, ohne den Engpass bei meinem Chef zu vergrößern?

In meiner Firma hat jeder Entwickler die Möglichkeit, sich zusammenzuschließen. Wir weisen eine Zusammenführungsanforderung einem anderen Entwickler zu und durchlaufen den Überprüfungs- / Feedback- / Aktualisierungszyklus, bis beide Parteien zufrieden sind. Dann führt der Prüfer den Code zusammen.

10-20 Zweige, die darauf warten, zusammengeführt zu werden, sind ein Zeichen dafür, dass Ihr Prozess fehlerhaft ist. Wenn wir so viele hätten, würde alle Entwicklungsarbeit aufhören, bis sie geklärt wäre.

Matthew
quelle
1
Nicht die Antwort, nach der ich gesucht habe, weil ich bezweifle, dass mein Chef seinen Griff um das Kofferraumdepot lockern wird. Trotzdem eine unglaublich hilfreiche Antwort, danke für den Einblick!
user6567423
5
@ user6567423: Wenn Ihr Chef zum Engpass wird, den er jetzt Ihrer Beschreibung zufolge hat, muss er entweder seine Herangehensweise ändern oder akzeptieren, dass er die Ursache für Verzögerungen ist (für die seine Mitarbeiter dann nicht verantwortlich gemacht werden können). Die Weigerung, Ihren Ansatz zu ändern, die von Ihnen verursachten Probleme zu ignorieren und die Schuld auf andere zu schieben, ist keine Möglichkeit, ein Unternehmen zu führen.
Flater
1
Er ist sich einig, dass er der Engpass ist, und er macht mit Sicherheit andere nicht dafür verantwortlich. Aber ja, ich habe nach Tipps gesucht, die nicht ohne weiteres ersichtlich sind und möglicherweise unseren Engpass verringern könnten. Danke für den Einblick
user6567423
1
@ user6567423 Ich bin gespannt, ob er jemals erklärt hat, warum er der einzige ist, der sich zum Kofferraum zusammenschließen kann.
Matthäus,
13

So funktionieren im Wesentlichen viele Open-Source-Projekte, darunter vor allem der Linux-Kernel, der viel mehr Zweige im Umlauf hat als Sie zu einem bestimmten Zeitpunkt. Der typische Weg, um Big Bang Merges in diesen Projekten zu vermeiden, besteht darin, einen weiteren Zweig (oder mehrere Zweige) für die kontinuierliche Integration zu erstellen. Dies ist der Zweig, mit dem Sie sicherstellen, dass Ihre Änderungen mit Ihren Kollegen zusammenarbeiten. Er wird regelmäßig auf den Stamm übertragen, wenn der Gatekeeper Überprüfungen vornimmt.

Optional können Sie diesen Zweig verwenden, um mehrere Ihrer eigenen Pull-Anforderungen zu einer großen zusammenhängenden Anforderung zu kombinieren, die Ihr Chef überprüfen soll. Linus Torvalds erhält normalerweise Pull-Anforderungen, die zwei oder mehr Ebenen tief integriert wurden und eine Größe in der Größenordnung von beispielsweise einem vollständig neuen Dateisystemtreiber haben können.

Karl Bielefeldt
quelle
Vielen Dank Ich denke, dass die Tipps zum Kombinieren von Branchen und Verhindern von Konflikten unsere beste Vorgehensweise sein werden.
user6567423
8

Ich bin mit Doc Brown einverstanden, sehe aber auch ein anderes Gegenmuster:

Mein Chef, der alleinige Verantwortliche für das Trunk-Repository , wird tatsächlich alle Überprüfungen von Zweigen auf einen bestimmten Zeitpunkt verschieben, an dem er so viele Überprüfungen wie möglich durchführt. Einige Zweige werden für Verbesserungen / Korrekturen zurückgeworfen, andere Zweige verschmelzen direkt mit dem Stamm, einige Zweige werden aufgrund von Konflikten usw. zurückgeworfen.

In meiner Demut gibt es einige Management-Antimuster:

  1. Er / sie ist die einzige Drosselstelle, die die Geschwindigkeit des Teams einschränkt. Ihr Busfaktor ist 1. Nach der Theorie der Einschränkungen sollten Sie sich bemühen, den langsamsten Teil der Kette zu verbessern.
  2. Ihr Manager verlangsamt Ihren Feedback-Zyklus und verringert die Beweglichkeit Ihres Teams. Können Sie jede Woche freigeben?
  3. Die Komplexität von Merges wächst exponentiell mit der Menge des Codes. Es ist besser, 10 Zusammenführungen mit 100 Zeilen als 1 von 1000 Zeilen durchzuführen. Das ist nur einer der Gründe, warum Sie es so schnell wie möglich tun sollten
  4. Wenn Sie einen Fehler im Kofferraum feststellen, werden Sie dies rechtzeitig tun. Welche der verschiedenen Branchen war die problematische
  5. Entscheidungen sollten von denen getroffen werden, die mehr über sie wissen. Wer weiß in diesem Fall mehr? Ich wette, dass die Entwickler den Code gemacht haben.
  6. Sie können einen Fehler in der Produktion nicht beheben, wenn Ihr Manager in den Ferien ist.
  7. Du machst die Arbeit wieder gut und wirfst Äste zurück. Das ist Zeitverschwendung . Die Zeit, die darauf wartet, die Produktion zu erreichen, ist auch Verschwendung.

Empfehlungen:

  • Ihr Manager muss die Verantwortung an das Team delegieren. Sie müssen zeigen, dass das Team ausgereift und professionell ist. Stellen Sie klar, dass sie dem Team vertrauen können
  • Implementieren Sie eine Überprüfungsmethode. Möglicherweise benötigen Sie die Genehmigung von zwei anderen Teammitgliedern.
  • Möglicherweise macht die Verwendung von SVN es schwieriger. Probieren Sie Git aus und sehen Sie, ob es Ihnen hilft. Sogar mehr. Wenn Sie GitHub verwenden, können Sie den Pull-Request-Mechanismus verwenden, sodass für eine Zusammenführung bestimmte Stimmen erforderlich sind.
  • Lesen und teilen Sie Informationen über agile Praktiken, kontinuierliche Integration und DevOps.
Borjab
quelle
7
Ich habe sowohl mit SVN als auch mit Git professionell gearbeitet, und ich würde sagen, dass SVN definitiv ein Teil des Problems ist: Es erzwingt eine Single-Merge-Back-Commit-Richtlinie für Zweige, die in Git nicht vorhanden sind. In Git sind alle Zusammenführungen gleich, in SVN sind einige gleich wie andere. Das Fehlen lokaler Commits erschwert das Experimentieren mit SVN erheblich als mit Git, und das Fehlen einer Staging-Zone trägt nur zur Inflexibilität von SVN bei. Es gibt einen Grund, warum Torvalds nicht einfach SVN verwendet hat, anstatt Git zu entwickeln ...
cmaster
Git ist meiner Meinung nach so viel besser als svn aus den Gründen, @cmaster und mehr ausgelegt
reggaeguitar
Ich bin damit einverstanden, dass Git wahrscheinlich einige unserer Probleme beim Zusammenführen lösen würde, und lieber Gott, ich würde es lieben, wenn Rebase verfügbar wäre. Aber ich glaube nicht, dass wir bald
umsteigen werden
1
@ user6567423, Ich habe letztes Jahr eine Konsultation durchgeführt, bei der ich einem kleinen Team beim Übergang von svn zu Git geholfen habe und deren Workflow geändert habe, einschließlich der Schulung auf Git und der Einrichtung mit GitLab Community Edition (Open Source) für Codeüberprüfungen und Zusammenarbeit . Sie waren sehr begeistert davon; Es war ein Unterschied zwischen Tag und Nacht. (Auch es dauerte nur drei Tage.)
Wildcard
2

Wenn Sie Feature-Arbeiten in separaten Zweigen ausführen, können Sie keine Integrationstests durchführen, bis einer der Zweige zum Trunk zusammengeführt und in die anderen Feature-Zweige gezogen wird. Nach meiner Erfahrung ist dies das Hauptproblem mit dem Anti-Pattern "Big Bang Merge". Idealerweise erledigen Sie die Feature-Arbeit, testen sie im Feature-Zweig, führen sie in Trunk zusammen und an diesem Punkt sind Sie mit dem Feature fertig. Wenn es nicht zusammengeführt wurde, müssen Sie es jedes Mal erneut aufrufen, wenn etwas anderes zuvor in trunk zusammengeführt wird. Der Schmerz dieses Anti-Patterns ist, dass am Ende des Entwicklungszyklus viele Fehler vom Typ Integration auftauchen.

bmm6o
quelle
1

Sie haben also 20 Filialen. Zweig 1 wird gerade zusammengeführt. Dann muss der Entwickler von Zweig 2 Zweig 1 in seinen Zweig einbinden, um ohne Konflikte in main einbinden zu können, und dann zusammenführen. Dann muss der Entwickler von Zweig 3 Zweig 1 und Zweig 2 in ihrem Zweig zusammenführen, um in der Lage zu sein, ohne Konflikt in Haupt zusammenzuführen, und dann zusammengeführt zu werden.

Übung für den Leser: Schreiben Sie ein Programm, das meinen vollständigen Beitrag druckt :-)

Das ist Wahnsinn. Sie werden unglaublich viel Zeit mit dem Zusammenführen verbringen.

gnasher729
quelle
Nun, nicht unbedingt, es sei denn, die Zweige stehen in Konflikt, dann kann er sie alle nahtlos in Trunk zusammenführen. In der Regel versuchen wir, Konflikte zu vermeiden, indem wir eine Testzusammenführung durchführen, bevor wir den Zweig zur Überprüfung einreichen. Die Konflikte treten jedoch unvermeidlich auf, wenn die Anzahl der Zweige in der Warteschlange zunimmt. Ich stimme allerdings zu, dass es sich wie Wahnsinn anhört.
user6567423
2
Normales Zusammenführungsverhalten von SVN, soweit ich das
beurteilen
0

Angesichts der Art und Weise, wie Sie arbeiten und Ihr Chef ein verantwortungsbewusster Kontrollfreak ist, scheint die Verzweigung selbst das Problem zu sein. Anstatt für jedes Feature eine Verzweigung zu erstellen, muss jeder Entwickler sein Feature in Teilen direkt in den Trunk übertragen. Dies belastet den Entwickler mit der Integration in mehreren kleineren Schritten (Win-Win). Gate Keeper kann kleinere Änderungen über einen längeren Zeitraum zu einem früheren Zeitpunkt im Entwicklungszyklus nachverfolgen und ist dennoch der Hauptprüfer.

Das Verzweigen selbst ist etwas, das Sie nicht tun möchten, es sei denn, Sie haben einen sehr guten Grund, dies zu tun, oder Sie haben keine andere Option. Sie sind klein genug, um die Dinge enger zu synchronisieren, was einfacher und sicherer ist.

Martin Maat
quelle
1
Und wie gehst du mit der Veröffentlichung um, wenn nur eine dieser Funktionen einen Fehler aufweist oder nicht rechtzeitig fertig ist? "Das Verzweigen selbst ist etwas, das Sie nicht tun möchten, es sei denn, Sie haben einen sehr guten Grund dafür."
Ivo van der Veeken
Es ging um zwei Dinge: Der Chef möchte der einzige Torhüter bleiben, und die Dinge dürfen nicht zu sehr voneinander abweichen. Ja, es wird einen Moment geben, in dem etwas vorangebracht wurde, das der Chef noch nicht überprüft hat. Er sollte dies jedoch schnell tun können und in dem unwahrscheinlichen Fall, dass er sofort liefern muss, die neuesten Commits wiederherstellen können. Dies wird die Dinge synchron halten und wenn Sie an irgendetwas scheitern, werden Sie mit Sicherheit schnell scheitern. Sieht für mich nach einem guten Kompromiss für die aktuelle Situation aus.
Martin Maat
1
Ich würde dies als letztes Mittel betrachten
reggaeguitar