kutombawewe.net

Wie gehen Sie mit der Integration von Code aus mehreren Zweigen / Entwicklern bei jedem Sprint um?

Ich habe gerade einen Retro-Anruf erhalten, bei dem Entwickler ihre Besorgnis über die Integration ihrer Geschichten in den Master-Zweig bei jedem Sprint zum Ausdruck brachten. Die Entwickler codieren alle in ihrem eigenen Zweig und gegen Ende des Sprints verschmelzen sie alle zu einem Hauptzweig.

Dann muss ein Entwickler (normalerweise derselbe) sicherstellen, dass alles gut in den Code anderer Entwickler integriert ist (die meisten Änderungen befinden sich auf derselben Seite. Zum Beispiel eine Datenanzeige-Story, eine Datenfilter-Story und a SLA Indikator).

Wie können wir diese Belastung reduzieren und die Zusammenführung unseres Codes erleichtern? Aus meiner Sicht kann es einige der Probleme lösen, wenn PO oder SM die Storys effizienter priorisieren, damit wir diese Art von Abhängigkeiten nicht im selben Sprint haben. Wie gehen alle anderen damit um? Oder ist das nur ein Teil des Prozesses?

42
cookiecutter

Wenn Sie Git verwenden, zieht jeder Entwickler aus dem Zweig develop in seinen eigenen Feature-Zweig, um sicherzustellen, dass er nicht zu weit von der aktuellen Basislinie entfernt ist. Sie können dies täglich tun, sodass Aufgaben, die länger als ein paar Tage dauern, synchron bleiben und Zusammenführungsprobleme gelöst werden, solange sie noch klein sind.

Wenn der Entwickler mit seiner Arbeit fertig ist, erstellt er ein Pull Request. Wenn dies genehmigt wurde, wird es in den Zweig develop eingefügt.

Der Zweig develop sollte immer über funktionierenden Code verfügen und jederzeit zur Veröffentlichung bereit sein. Wenn Sie tatsächlich eine Version erstellen, führen Sie develop zu master zusammen und markieren sie.

Wenn Sie über einen guten Continuous Integration Server verfügen, wird jeder Zweig beim Einchecken von Änderungen erstellt - insbesondere bei Pull-Anforderungen. Einige Build-Server werden in Ihren Git-Server integriert, um eine Pull-Anforderung automatisch zu genehmigen oder abzulehnen, wenn der Build fehlschlägt oder die automatisierten Tests fehlschlagen. Dies ist ein weiterer Weg, um mögliche Integrationsfehler zu finden.

88
Berin Loritsch

Ich habe in einem Team gearbeitet, in dem wir mit dem gleichen Problem zu kämpfen hatten. Wir stellten fest, dass es umso weniger schwierig wurde, je weniger Zeit wir vor der Integration hatten. Ich weiß, dass die meisten Leute, die kontinuierliche Integration unterrichten, alle paar Minuten über das Festschreiben sprechen - wir haben uns wahrscheinlich tatsächlich jede Stunde oder so verpflichtet.

Wir fanden auch, dass nur das Bauen nicht genug war. Wir brauchten eine gute Testabdeckung, um sicherzustellen, dass wir nicht versehentlich den Code der anderen brechen.

23
Daniel
  • Halten Sie Ihre Filialen kurzlebig (es hört sich so an, als würden Sie dies bereits tun).
  • Lassen Sie Ihre Testergebnisse für sich sprechen.
  • Warten Sie nicht bis zum Ende des Sprints.

Sie müssen TDD für dieses nicht einmal abonnieren. Sie benötigen lediglich einige Tests, die belegen, dass die Funktionen Ihrer Entwickler ordnungsgemäß funktionieren. Dies können Unit-Tests und Integrationstests sein, im Idealfall handelt es sich jedoch um einige automatisierte End-to-End-Tests der kritischen Funktionen. Standard-Regressionspaket.

Sobald Ihre Zusammenführung abgeschlossen ist, können Sie den Automatisierungstestbericht gemeinsam überprüfen und sicherstellen, dass alles erfolgreich integriert wurde.

Ich stimme einer der anderen Antworten zu, bei denen der Autor erklärte, Git PRs würden dieses Problem lösen, indem sie jeden Entwickler dazu bringen, seine eigene Arbeit zusammenzuführen.

Ein weiterer Punkt, den ich für wichtig genug halte, um ihn bis zum letzten Absatz zu belassen. Ich schlage vor, dass Sie manuelle Tests für Ihre nächtlichen Builds durchführen, anstatt bis zum Ende des Sprints zu warten. Entwickler sollten sich zusammenschließen, sobald die Funktion abgeschlossen ist, damit sie so schnell wie möglich integriert, bereitgestellt und getestet werden kann.

12
Liath

nicht

Abhängig von Ihrer Sprache und den Dateien, die Sie bearbeiten, ist es möglicherweise nicht für jeden Entwickler sinnvoll, sie in seinem eigenen Zweig zu bearbeiten. In C # habe ich beispielsweise festgestellt, dass es am besten ist, wenn nur eine Person gleichzeitig UI-Designerdateien bearbeitet. Dies sind automatisch generierte Dateien, und so wird Code manchmal ohne ersichtlichen Grund verschoben - und dies führt bei den meisten Zusammenführungswerkzeugen zu Chaos.

Dies bedeutet, dass einige Storys andere Storys blockieren können, bis die UI-Arbeit abgeschlossen ist. Und/oder es wird eine neue Story erstellt, um nur die Benutzeroberfläche zu gestalten, während die anderen Storys Funktionen implementieren. Oder vielleicht erledigt ein Entwickler die gesamte UI-Arbeit, während andere die Funktionalität dieser UI implementieren.

Wenn Sie wissen, dass mehrere Storys alle dieselbe (n) Datei (en) berühren, möchten Sie möglicherweise vermeiden, dass Sie alle gleichzeitig bearbeiten. Ziehen Sie sie nicht alle in den gleichen Sprint oder arbeiten Sie erst an ihnen, wenn einer oder mehrere fertig sind.

6
mmathis

Ein weiterer möglicher Ansatz zur Vermeidung von späten und großen Zusammenführungen sind Feature-Flags : Sie schützen Ihre Änderungen mit einem (idealerweise dynamisch) konfigurierbaren Flag, das verhindert, dass sie zuvor aktiv werden beabsichtigt.

Auf diese Weise können Sie Ihre Änderungen frühzeitig wieder in master oder Ihren gemeinsamen Entwicklungszweig zusammenführen, ohne etwas zu beschädigen. Andere Entwickler können diese Änderungen dann wieder in ihren Feature-Zweigen zusammenführen (oder ihre Zweige entsprechend neu gründen).

Wie die anderen Antworten bereits gezeigt haben, sollte dies mit einer kontinuierlichen Integrationslösung kombiniert werden.

Feature-Flags bieten zusätzliche Vorteile (z. B. erleichtern sie die Durchführung von A/B-Tests). Siehe dieser Artikel von Martin Fowler für weitere Informationen.

2
Florian Brucker

Wir verfolgen einen Ansatz eines separaten Entwicklungszweigs für jedes Feature und führen dann die Zweige zu einem QS-Zweig zusammen, um sie in einer Integrationstestumgebung zu testen.

Sobald der Regressions- und Integrationstest abgeschlossen ist, können wir die sofort einsatzbereiten Funktionen problemlos in den Release-Zweig verschieben.

Wenn alles gut geht, führen wir den Release-Zweig wieder zum Master-Zweig zusammen.

0
emarshah

Einfach ausgedrückt, das Festschreiben und Zusammenführen verringert häufig das Zeitfenster für Zusammenführungskonflikte und reduziert Konflikte erheblich. Der andere Teil ist in der Tat die Planung durch die Leitung, die weiterhin einen reibungslosen Arbeitsablauf gewährleisten kann.

Die anderen Antworten geben einen guten Einblick in die Best Practices für Commits. Wenn Sie diese einfach befolgen, reduzieren Sie wahrscheinlich die überwiegende Mehrheit Ihrer Zusammenführungsprobleme. Weitere Zusammenschlüsse sind mit ziemlicher Sicherheit erforderlich, aber für ein kleineres Team funktioniert Ihr Ansatz für Zweigniederlassungen pro Person wahrscheinlich gut genug. Natürlich tut es nicht viel weh, sich auf erweiterbare Praktiken einzulassen!

Es scheint jedoch, dass niemand eine Ihrer wichtigsten Fragen beantwortet hat - was zu tun ist, wenn Sie alle dieselben Codebereiche berühren. Hier ist es hilfreich, einen Lead zu haben, der mit der Codebasis vertraut ist und Abhängigkeiten verschiedener Aufgaben erkennen kann. Wenn sie das Timing von Arbeit und Commits nicht koordinieren, kommt es wahrscheinlich zu Zusammenführungskonflikten und zeilenweiser Auflösung. Das Organisieren der Aufgaben\Timing ist bei einem größeren Team viel schwieriger, aber bei einem kleinen Team ist es möglich, diese widersprüchlichen Aufgaben zu identifizieren. Der Leiter könnte dann sogar alle damit verbundenen Aufgaben auf denselben Ingenieur verlagern, um den Konflikt insgesamt zu vermeiden.

0
Mars