Führt mein Unternehmen Filialen falsch zusammen?

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.

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.

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.

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.

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.

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.

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.

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.