Ich versuche, folgendes Problem zu lösen, das wir in unserem Unternehmen haben: Wir versuchen, SCRUM zu folgen. Wir verwenden ein Git-Flow-ähnliches Verzweigungsmodell. Wenn wir auf eine größere Geschichte stoßen, die 2,3 Sprints dauert, wird sie nicht zurückgeführt, bis alle Untergeschichten fertig sind. Infolgedessen haben wir einen lang laufenden Zweig, der am Ende schwer zusammenzuführen ist. Wir beginnen andere Geschichten basierend auf einem Master-Zweig, der aufgrund des großen Feature-Story-Zweigs nicht auf dem neuesten Stand ist. Ich habe vorgeschlagen, frühe Untergeschichten wann immer möglich wieder mit dem Master zusammenzuführen, aber das Management sagte, dass dies zu riskant sei, da die Änderungen Bereitstellungen unterbrechen könnten. Wie gehen Sie mit lang laufenden Geschichten und Verzweigungen um?
Die Idee von Scrum ist es, die Arbeit in Sprints zu beenden, damit Sie Ihren Fortschritt transparent machen können. Wenn Sie Geschichten haben, die sich über 2-3 Sprints erstrecken, verstecken Sie den Fortschritt und machen das Scrum-Framework weniger transparent.
Es wäre eine gute Idee, sich darauf zu konzentrieren, die größeren Geschichten aufzuschlüsseln. Dies kann zunächst eine Herausforderung sein, aber es ist eine Fähigkeit, die Scrum-Teams erwerben müssen, um erfolgreich zu sein.
Wenn Sie feststellen, dass Sie noch langlebige Feature-Zweige pflegen müssen, ziehen Sie den folgenden Ansatz in Betracht:
"Wenn wir auf eine größere Geschichte stoßen, die 2,3 Sprints dauert" .
Arbeite nicht daran herum, repariere es. Sie sollten in der Lage sein, eine INVEST - Story zusammenzuführen. Beachten Sie, dass das S für klein steht. Machen Sie Ihre Untergeschichten wertvoll und kombinierbar. Monolithische Geschichten zu haben ist ein riesiges (aber sehr häufiges) Problem. Ich vermute, Ihre Untergeschichten ähneln eher Phasen in einem technischen Design als ausführbaren Inkrementen. Das ist nicht ganz richtig. Die Leute schreiben Bücher über solche Dinge, aber ich verlinke Sie nur mit einem sehr einfachen und nützlichen Flussdiagramm , das zeigt , wie Sie an die Unterteilung Ihrer Geschichten herangehen.
„Wir beginnen andere Geschichten basierend auf einem …“ Sie haben zu viel Work in Progress (WIP) und dies ist einer der kleineren Ärgernisse. Werden Sie besser in der Zusammenarbeit und bauen Sie weniger Geschichten auf.
'aber das Management sagte, es sei zu riskant' .
Erstens könnte dies mit Ihrem WIP-Problem zusammenhängen. Wenn Sie Ihre Multi-Sprint-Geschichte beendet haben (episch ist vielleicht ein besseres Wort), gibt es immer auch eine andere Hälfte der Arbeit im Flug. Sie wollen nicht, dass alles im Master ist, aber die Lösung besteht nicht darin, es herauszunehmen, sondern weniger WIP zu haben.
Zweitens müssen die Geschichten, die Sie bei jeder Iteration aufgreifen (Entwicklung, QA in Testumgebungen usw.), mithilfe der Fähigkeiten Ihres Teams erstellt werden. Sie müssen jede Iteration veröffentlichen, das ist der Punkt. So liefern Sie Mehrwert und erhalten schnell Kundenfeedback. Dagegen muss man sich wehren. Aber Sie müssen auch sicherstellen, dass Sie hohe Qualitätsstandards haben (dh viel Testautomatisierung), damit die Leute nicht das Gefühl haben, dass die Übernahme Ihres Codes ein großes Risiko darstellt.
TLDR Die Lösung ist kein schlaues Zweigmanagement und Git kann Sie nicht retten. Teilen Sie Ihre Geschichten auf und lesen Sie nach, was Iterationen erreichen sollen. Oder, nehme ich an, Budget für schreckliche Fusionen.
Wir verwenden die Feature-Toggle-Technik ( [Wikipedia Feature Toggle]: https://en.wikipedia.org/wiki/Feature_toggle ) und waren bisher sehr effektiv darin, rechtzeitig zu liefern, große Features elegant zu handhaben und Features abzuschalten die bis zum Erscheinungsdatum noch nicht fertig sind.
Ein Feature-Toggle (auch Feature-Schalter, Feature-Flag, Feature-Flipper, bedingtes Feature usw.) ist eine Technik in der Softwareentwicklung, die versucht, eine Alternative zur Verwaltung mehrerer Quellcode-Zweige (bekannt als Feature-Zweige) bereitzustellen.
Continuous Release und Continuous Deployment bieten Entwicklern schnelles Feedback zu ihrer Codierung. Dies erfordert die möglichst frühzeitige Integration ihrer Code-Änderungen. Feature Branches führen eine Umgehung dieses Prozesses ein. Feature-Toggles bringen Entwickler wieder auf die Spur, aber die Ausführungspfade ihrer Features sind immer noch "tot", wenn ein Toggle "off" ist. Der Aufwand ist jedoch gering, um die neuen Ausführungspfade einfach durch Setzen eines Schalters auf „on“ zu aktivieren.
Die Technik ermöglicht es Entwicklern, eine Version eines Produkts mit unvollendeten Funktionen zu veröffentlichen. Diese unvollendeten Funktionen sind ausgeblendet (umgeschaltet), sodass sie nicht in der Benutzeroberfläche angezeigt werden. Dadurch können viele kleine inkrementelle Softwareversionen ohne die Kosten für ständiges Verzweigen und Zusammenführen bereitgestellt werden.
Ein weiterer Vorteil von Feature-Flags sind Canary-Starts. Bei einem Canary Launch (auch bekannt als Canary Deployment oder Canary Release) werden Funktionen für eine kleine Anzahl von Benutzern bereitgestellt, um die Reaktion des Gesamtsystems zu bewerten. Mit einem Canary-Launch können Sie eine Funktion langsam einführen und die Reaktion echter Benutzer-„Canarys“ messen, um nach Frühindikatoren für Gefahren zu suchen. Wenn eine Funktion nicht gut ist, kann sie rückgängig gemacht werden. Canary-Einführungen sind eine Best Practice für agile Entwicklungsorganisationen, die Continuous Delivery praktizieren, um schneller voranzukommen.
Wir definieren ein lieferbares Feature als ein Minimum Viable Product MVP, das normalerweise als Epic übersetzt wird, das sich über viele Sprints oder innerhalb eines Sprints (unser Sprint dauert eine Woche) erstrecken kann. Ein Epic wird in mehrere INVEST-Benutzergeschichten aufgeteilt, hoch Ebene und kundenorientiert. Alle fertigen User Stories werden täglich in den Master-Branch gemergt.
Andere haben die Tatsache angesprochen, dass Ihre Geschichten zu umfangreich sind, aber wenn Sie sie aufschlüsseln ( und Sie sollten ), werden Sie Geschichten gemacht haben, die vielleicht nicht ganz bereit für die „Prime Time“ sind. Sie möchten diese halbfertigen Funktionen nicht bereitstellen und Ihre Marketingabteilung auch nicht.
Aber hier ist das Geheimnis ...
Sie möchten sie bereitstellen. Es ist Ihre Marketingabteilung, die das nicht will. Und ihr habt beide Recht .
Das Marketing möchte nicht, dass halbfertige Funktionen produziert werden, aber Sie möchten diese Änderungen zusammenführen und bereitstellen, damit es einfacher ist. Du machst also beides.
Schreiben Sie einen Feature-Schalter für diese seit langem in Bearbeitung befindlichen Features. Fügen Sie Ihre Geschichten zusammen, wenn sie fertig sind, genau wie jede andere Geschichte. Jetzt schalten Sie die Funktion zu Test-/Demozwecken ein, aber für die Produktion aus . Auf diese Weise können Sie häufig zusammenführen, die Funktion für schnelles Feedback an Ihren QA- und Product Owner senden, sie aber für Ihre Endbenutzer "unversendet" lassen.
Wie man das macht, könnte leicht eine Reihe von Blog-Beiträgen füllen, also überlasse ich Ihnen die weitere Recherche zu Feature-Toggles.
Komische Argumentation, Ihr Management. Das frühzeitige Zusammenführen des Zweigs birgt das Risiko, Bereitstellungen zu unterbrechen, daher ist es besser, diesem Zweig viel mehr Code hinzuzufügen, bevor Sie ihn zusammenführen. Wie genau, sagen Sie mir, verringert das Hinzufügen von Code für viele Wochen das Risiko, die Bereitstellung zu unterbrechen?
Automatisieren Sie Ihre Bereitstellung und stellen Sie sie häufig in einer Testumgebung bereit. Streben Sie täglich an, aber häufiger, wenn Sie können. Auf diese Weise wird Ihre "kaputte Bereitstellung" immer durch die wenigen Codezeilen verursacht, die Sie gerade geschrieben haben. Einfach zu beheben.
Ihr Management hat Humor.
Das Zusammenführen eines veralteten Zweigs mit dem Master ist einfacher, wenn Sie eine neue Verzeichnisstruktur für die neue Funktion erstellen und dann eine interaktive Zusammenführung anstelle einer automatischen Zusammenführung durchführen:
Das Schreiben von Inline-Assertionen hilft immens bei großen Geschichten. Führen Sie eine Codeüberprüfung der Behauptungen durch und erstellen Sie am Ende jedes Sprints einen Testbericht, um den Fortschritt anzuzeigen. Dies vermeidet die Notwendigkeit von:
Verweise
Todd A. Jacobs
Ewan
Pedro