Entwickler haben darauf gewartet, dass der Code mit GitFlow aus einem anderen Zweig zusammengeführt wird

Unser Team hat gerade von FogBugz & Kiln / Mercurial zu Jira & Stash / Git gewechselt. Wir verwenden das Git Flow-Modell zum Verzweigen und fügen Nebenaufgabenzweige von Feature-Zweigen hinzu (in Bezug auf Jira-Nebenaufgaben von Jira-Features). Wir verwenden Stash, um einen Prüfer zuzuweisen, wenn wir eine Pull-Anforderung zum Zusammenführen zurück in den übergeordneten Zweig erstellen (normalerweise entwickeln, aber für Unteraufgaben zurück in den Feature-Zweig).

Das Problem besteht darin, dass selbst bei optimaler Planung und Aufschlüsselung von Feature-Fällen mehrere Entwickler gemeinsam an demselben Feature arbeiten, z. B. im Front-End und im Back-End, wenn sie an voneinander abhängigem Code arbeiten in getrennten Zweigen blockiert ein Entwickler den anderen.

Wir haben versucht, bei der Entwicklung zwischen den Zweigen der anderen zu wechseln. Wir haben auch versucht, lokale Integrationszweige zu erstellen, die jeder Entwickler aus mehreren Zweigen ziehen kann, um die Integration während der Entwicklung zu testen. Schließlich, und dies scheint möglicherweise das Beste für uns bisher zu sein, obwohl wir mit ein wenig mehr Aufwand versucht haben, einen Integrationszweig von Anfang an aus dem Feature-Zweig zu erstellen. Wenn eine Teilaufgabenverzweigung (außerhalb der Featureverzweigung) für eine Pull-Anforderung und eine Codeüberprüfung bereit ist, führen wir diese Änderungssätze auch manuell in dieser Featureintegrationsverzweigung zusammen. Dann können alle interessierten Entwickler aus diesem Integrationszweig in andere abhängige Subtask-Zweige ziehen. Dies verhindert, dass jemand auf einen Zweig wartet, auf den er angewiesen ist, um die Codeüberprüfung zu bestehen.

Ich weiß, dass dies nicht unbedingt ein Git-Problem ist - es hat mit der Arbeit an voneinander abhängigem Code in mehreren Zweigen zu tun, gemischt mit unserem eigenen Arbeitsprozess und unserer eigenen Kultur. Wenn wir nicht die strikte Codeüberprüfungsrichtlinie für Develop (True Integration Branch) hätten, könnte Entwickler 1 zusammengeführt werden, um zu entwickeln, von dem Entwickler 2 ausgehen kann. Eine weitere Schwierigkeit besteht darin, dass wir im Rahmen des Codeüberprüfungsprozesses einige vorläufige Tests durchführen müssen, bevor wir die Funktion an die Qualitätssicherung übergeben. Dies bedeutet, dass auch Front-End-Entwickler 1 direkt vom Zweig von Back-End-Entwickler 2 abzieht, sobald sie verfügbar sind Los, wenn Back-End-Entwickler 2 fertig ist und seine Pull-Anforderung eine Woche lang in der Codeüberprüfung sitzt, kann Front-End-Entwickler 2 seine Pull-Anforderung / Codeüberprüfung technisch nicht erstellen, weil sein Codeüberprüfer dies nicht kann Test, weil Back-End-Entwickler 2 '

Unterm Strich befinden wir uns in diesem Fall in einer viel serielleren als in einer parallelen Herangehensweise, je nachdem, welchen Weg wir gehen, und möchten einen Prozess finden, um dies zu vermeiden.

Das Letzte, was ich erwähnen möchte, ist, dass wir Code zwischen Zweigen teilen, die noch nicht überprüft und finalisiert wurden. Wir verwenden im Wesentlichen den Beta-Code anderer. Bis zu einem gewissen Grad denke ich, dass wir das nicht vermeiden können und bereit sind, dies bis zu einem gewissen Grad zu akzeptieren.

Das Problem könnte auch in einer zu strengen Aufgabentrennung zwischen Back-End- und Front-End-Entwicklung liegen.

Wenn ein Front-End-Entwickler eine neue API benötigt, kann er dann keine Dummy-API für das Back-End erstellen (z. B. immer denselben Wert zurückgeben), um das Layout zu validieren. Setzen Sie dann diese teilweise Implementierung mit einem Stub fest, und in einem zweiten Mal implementiert ein Back-End-Entwickler das eigentliche Feature.

Wenn Sie die Abhängigkeit aufheben, erhalten Sie einen besseren Ablauf, und es muss nicht alles auf eine einzelne Aufgabe warten, die als Engpass fungiert.

Ihr Problem: Entwickler A-Verzweigungen von Master, Entwickler B-Verzweigungen von Master, beide arbeiten an eng verwandten Funktionen, und die unvermeidliche Tatsache, dass das Zusammenführen in die Master-Verzweigung aufgrund unvermeidlicher Konflikte schwierig ist, hält alle zurück.

Wenn dies vorhersehbar ist, könnten A und B zuerst einen gemeinsamen Zweig erstellen, dann jeden Zweig für seine eigene Arbeit von diesem gemeinsamen Zweig trennen, jeden ihrer eigenen Arbeiten in den gemeinsamen Zweig zusammenführen, und jetzt haben Sie einen konfliktfreien Zweig, der viel ist einfacher zu integrieren.

Wenn Entwickler 1 an Feature A arbeitet und Entwickler 2 die Arbeit an Feature B beendet hat, das von Feature A abhängt, führt kein Weg daran vorbei - das Zusammenführen von Feature B wird angehalten. Sie können es nicht ohne Feature A testen, und es macht noch keinen Sinn, es zu überprüfen, da ein weiterer Fortschritt in Feature A zu Änderungen in Feature B führen kann.

Dies bedeutet jedoch nicht, dass Entwickler 2 angehalten wird! Entwickler 2 kann mit der Arbeit an Feature C beginnen und nach Abschluss von Feature A zum Überprüfungszyklus von Feature B zurückkehren. Ich weiß, dass das Wechseln des Kontexts nicht optimal ist, aber da die Zeit bis zur Fertigstellung von Feature A wahrscheinlich in Tagen gemessen wird, ist es nicht so schlimm (Sie ziehen sie nicht für eine 15-minütige Nebenaufgabe aus "The Zone" heraus).

Eine Sache, die Sie tun können, um die Situation zu verbessern, besteht darin, Wege zu finden, um den Entwicklungszyklus zu verkürzen.

Wenn ein Entwickler auf ein Feature eines anderen Entwicklers wartet, kann ein Teil der Arbeit des ersten Entwicklers vor dem gesamten Feature eine Überprüfung und Integration durchlaufen, um den Block freizugeben?

Gibt es Möglichkeiten, Features in kleinere Arbeitseinheiten aufzuteilen, um den Integrationszyklus am Laufen zu halten?

Wie lange dauert die Integration? Wenn sich ein Build oder eine Integration lange herumspricht, kann dies die gesamte Warteschlange verlangsamen. Prüfen Sie, ob Sie die Erstellungszeit beschleunigen können, damit die Warteschlangen schneller freigegeben werden.