Wie können wir nur alle zwei Wochen sofort einsatzbereite Funktionen in unsere Produktionsversionen aufnehmen?

Ich bin ein Softwareentwickler in einem ziemlich großen agilen Team (wir haben acht Entwickler, die aktiv Änderungen an einem einzelnen Code-Repository vornehmen). Alle zwei Wochen bringen wir eine neue Version unserer Software in die Produktion. Hier ist unser aktueller Workflow:

• Beim Starten einer neuen Aufgabe erstellen Entwickler einen "Feature-Zweig" aus dem Hauptentwicklungszweig (wir verwenden git ) und arbeiten diesen neuen Zweig ab
• Sobald ein Entwickler die Arbeit an seiner Aufgabe beendet hat, führt er seinen Feature-Zweig wieder in den Entwicklungszweig ein
• Der Entwickler führt den Entwicklungszweig in den QS-Zweig ein.
• Ein Build wird aus dem QA-Zweig ausgelöst. Die Ausgabe dieses Builds wird in unserer QS-Umgebung bereitgestellt, damit die Tester mit dem Testen beginnen können.

Es ist durchaus üblich, dass unsere Tester Probleme mit diesen neuen Funktionen finden, die in den QS-Zweig integriert wurden. Dies bedeutet, dass die QS-Umgebung zu einem bestimmten Zeitpunkt wahrscheinlich mehrere neue Funktionen enthält - einige getestet und fehlerfrei, andere defekt. Dies erschwert die Freigabe, da sich der QS-Build selten in einem produktionsbereiten Zustand befindet.

Um dies zu mildern, haben wir versucht, ein "QA-Freeze" einzuleiten, was bedeutet, dass Entwickler unseren Entwicklungszweig einige Tage vor der Veröffentlichung nicht mit dem QA-Zweig zusammenführen. Fehlerbehebungen an der QA-Umgebung werden direkt im QA-Zweig vorgenommen und bis zum Entwicklungszweig zusammengeführt. Theoretisch hält dies neue, defekte Funktionen von der Qualitätssicherung fern und ermöglicht es uns dennoch, Probleme zu beheben, die bereits in der Qualitätssicherung vorhanden sind.

Obwohl dieses "QA Freeze" -Konzept teilweise erfolgreich war, ist es schwer zu koordinieren und die Leute sind oft verwirrt darüber, ob sie zur QA fusionieren dürfen. Es war auch schwierig, eine Frist für das "Einfrieren der Qualitätssicherung" festzulegen - jeder mag die Idee, zwischen dem Einfrieren und der Veröffentlichung eine Atempause einzulegen, aber in der Praxis möchten sie ihre Funktion lieber in der nächsten Veröffentlichung haben, als die Frist einzuhalten.

Gibt es eine bessere Möglichkeit, um sicherzustellen, dass wir alle zwei Wochen einen sauberen Build für unsere Releases haben?

Es gibt einige Probleme, die Probleme verursachen, die auftreten.

Der erste ist der langjährige QS-Zweig. Ein lang laufender Zweig, der parallel zur Entwicklungshauptleitung verläuft, kann zu Verwirrung führen, da sowohl im QA-Zweig als auch in der Hauptleitung unterschiedliche Anstrengungen unternommen werden müssen. Dies bedeutet, dass Sie entweder Fixes für den QA-Zweig einchecken, die mit der Hauptleitung zusammengeführt werden müssen (keine schlechte Sache), oder Sie checken für die Hauptleitung ein, die mit dem QA-Zweig zusammengeführt wird (eine Quelle möglicher Fehler). .

Das andere Problem mit dem lang laufenden parallelen Zweig besteht darin, dass Dateien möglicherweise nicht mehr synchron sind. Ein Code-Fix, der niemals wieder zusammengeführt wird, oder eine Konfiguration, die für Produktions-Builds benötigt wird, die niemals getestet werden und Teil der Entwicklungshauptlinie sind.

Als nächstes haben Sie Rollen, die beeinflusst werden. Dies bedeutet, dass die Verpackungsrolle (dazu später mehr) nicht ausreichend isoliert wird.

Im Git-Flow- Modell wird der Release-Zweig von der Entwicklung verzweigt ( nicht die Entwicklung wird mit der Qualitätssicherung zusammengeführt), und alle Fixes werden in den Release-Zweig eingecheckt und dann wieder in den Entwicklungszweig zusammengeführt.

Ein Teil der Verzweigungsphilosophie findet sich in Advanced SCM Branching Strategies (ich halte dies für eine hervorragende Lektüre). Dies konzentriert sich auf die Rollen, die jeder Zweig übernehmen kann. Der Release-Zweig übernimmt die Verpackungsrolle.

Die Verpackungsrolle wird häufig mit der Akkumulations- oder häufiger mit der Hauptrolle verwechselt. Sobald die beabsichtigte Entwicklung und Wartung durchgeführt wurde und eine Akkumulation durchgeführt wurde, ist es Zeit, den Code für die Veröffentlichung vorzubereiten. Ein solcher Aufwand ist möglicherweise nicht trivial und erfordert ein Team von Release-Ingenieuren und zusätzliche Korrekturen, die über die bereits durchgeführten hinausgehen. Die Richtlinien für eine Verpackungsbranche unterscheiden sich erheblich von denen für eine Wartungsbranche. Wie aus der Verpackungsrolle hervorgeht, sollten nur die Änderungen berücksichtigt werden, die erforderlich sind, um das Produkt freigebbar zu machen.

• Verzweigen Sie vom Entwicklungspunkt zum Release-Zweig. Der Release-Zweig, aus dem die Qualitätssicherung erstellt wird, erhält einen Zweig und wird nicht aus der Entwicklung zusammengeführt.
  • Wenn Sie diesen Weg mit einheitlichen Namen und Hooks beschreiten möchten, können Sie verhindern, dass eine Zusammenführung zu einem Release-Zweig durchgeführt wird.
• Korrigieren Sie alles, was im Release-Zweig repariert werden muss, und führen Sie diese Änderungen wieder in der Hauptzeile zusammen.
• Führen Sie am Ende des Release-Vorgangs den Release-Zweig in den Zweig "Releases go here" ein und kennzeichnen Sie ihn als solchen.
  • Einige Websites haben keinen Zweig "Releases go here" und lassen das Ende des Release-Zweigs nur mit einem Tag baumeln.

Man sollte ernsthaft darüber nachdenken, den gesamten Git-Flow an Ort und Stelle anzuwenden. Dies ist nicht allzu weit von dem entfernt, was derzeit getan wird, und bringt Disziplin und Beständigkeit in das, was jeder Zweig bedeutet und wie jeder Zweig mit anderen interagiert.

Das Problem scheint mir zu sein, dass Sie eine einzige QS-Niederlassung haben.

Erstellen Sie für jede Version einen separaten QS-Zweig vom primären Entwicklungs-Trunk / Master. Führen Sie dann nur Korrekturen für Fehler für Funktionen in diesem Zweig ein - niemals neue Funktionen. Lassen Sie diesen Zweig von der Qualitätssicherung testen.

Auf diese Weise ist das "Einfrieren" ziemlich offensichtlich - es ist im Filialnamen. Sie könnten so etwas gebrauchen, ich weiß nicht release/26/10/2015. Dann ist es offensichtlich, dass danach niemand mehr neue Funktionen einbinden sollte.

Es ist besonders hilfreich, wenn Sie den Zweig erst nach dem Einfrieren gabeln. Die Leute können sich jederzeit zum Master zusammenschließen. Es wird einfach nicht Teil dieser Version sein, wenn es nicht rechtzeitig zum Testen fertig ist.

Haben Sie keine einzige langjährige QS-Niederlassung, die nur um Ärger bittet. Fork aus dem Hauptentwicklungszweig für jede Version und Qualitätssicherung in diesem Zweig.

Sie sind etwas auf das unten gezeigte Verzweigungsmodell Development-MAIN-Production abgebildet. Das Gebiet über MAIN soll das Entwicklungsgebiet sein. Der Bereich unter MAIN ist der Produktionsbereich.

Highlights dieses Modells, die ich für relevant halte:

• Ihre Entwickler müssen häufig (2-3 Mal pro Woche) Forward Integrate (FI) (FI = Merge Away from MAIN) in ihre DEV-Filialen, um sicherzustellen, dass ihre neuesten Änderungen immer die neuesten Gesamtentwicklungen berücksichtigen.
• Ihre Entwickler müssen Reverse Integrate (RI) (RI = Merge in Richtung MAIN) im TEST-Zweig nur dann ausführen, wenn sie einen Meilenstein für die Fertigstellung von Funktionen erreicht haben, den sie der Qualitätssicherung aussetzen möchten und für den sie bereit sind, umgehend Korrekturen vorzunehmen Antwort auf QS-Feedback. Die Korrekturen werden im TEST-Zweig und sofort im FI-Zweig durchgeführt.
• Niemals RI von einer DEV-Niederlassung in MAIN
• RI immer von der TEST-Niederlassung in MAIN, ausschließlich wenn Ihre Qualitätssicherung die Qualität von TEST für OK hält. Halten Sie einen hohen Qualitätsschwellenwert für die Zusammenführung mit MAIN ein. Zumindest muss Ihr Produktmanager in der Lage sein, immer eine funktionierende Version Ihres Produkts vom neuesten Commit in MAIN zu testen.
• Erstellen Sie Filialen im Produktionsbereich nur nach Bedarf. Ihr Build-Server sollte immer alle Zweige kennzeichnen, einschließlich derjenigen aus dem Entwicklungsbereich, und die Quelle eines Builds / Releases sollte jederzeit identifizierbar sein, unabhängig davon, aus welchem ​​Zweig er stammt.
• Nehmen Sie Freigaben für die Produktion nur von MAIN oder dem Produktionsbereich. Wenn Sie später einen Fix für eine exakt veröffentlichte Version bereitstellen müssen (dh Sie können nicht einfach die neueste Version von MAIN angeben), erstellen Sie eine Verzweigung im Produktionsbereich aus dem MAIN-Tag der fehlerhaften Version, wenn der Fix benötigt wird. Beheben Sie das Problem immer in der HotFix-Verzweigung und dann sofort RI in MAIN und FI in TEST.

Ich vermute, Sie haben Probleme, weil:

• Ihr Entwickler RI in TEST-Code, der nicht vollständig ist
• Ihre Entwickler nehmen an TEST teil, ohne grünes Licht von QA zu erhalten (dh QA hat keine Kontrolle darüber, was in TEST injiziert wird).
• Wenn QA einen Fehler bei TEST meldet, beheben Ihre Entwickler ihn in ihrem DEV-Zweig und dann RI in TEST. Dies ist eine sehr schlechte Praxis, da die Zusammenführung immer anderen unvollständigen Entwickler-Mist einbringt. Sie sollten es immer auf TEST und dann FI in ihrer DEV-Filiale beheben. Wenn es bei TEST nicht reparierbar ist, haben sie in erster Linie totaler Mist geliefert und Sie haben größere Probleme.
• Ihre Entwickler FI nicht oft genug von TEST und destabilisieren TEST, wenn sie dort liefern. Es ist eine Kunst, wie oft FI in DEV ausgeglichen wird. Verschieben Sie es zu sehr und es wird extrem teuer und riskant sein, kurz vor der Lieferung, was Sie nie wollen. Tun Sie es zu oft und Sie erhalten keine eigentliche Entwicklungsarbeit, wenn Sie sich in der Zwischenzeit zu sehr mit der Arbeit anderer Leute in TEST überschneiden.

Soweit ich die Frage verstehe, haben Sie zwei Probleme. (a) defekte Features werden mit den guten Features zusammengeführt, die Sie veröffentlichen möchten; (b) Sie möchten in der Lage sein, die guten Funktionen freizugeben, während Sie die defekten zurückhalten. Als Einschränkung möglicher Lösungen gehe ich davon aus, dass Ihre endgültigen / offiziellen QS-Tests in einem integrierten Zweig durchgeführt werden sollen, der alle Funktionen enthält, die für die nächste Version vorgesehen sind.

Unabhängig von Ihrem SCM-Verzweigungsmodell empfehlen wir Ihnen, eine oder beide der folgenden Methoden auszuprobieren:

1. Weisen Sie jedem Feature-Team eine QS-Ressource zu. Lassen Sie sie einige Feature-Tests für Builds aus dem Feature-Zweig durchführen und geben Sie ihnen die Berechtigung, zu entscheiden, wann ein Feature zum Zusammenführen gut genug ist. Lassen Sie sie im Idealfall mit (dem Rest) des Feature-Teams zusammenarbeiten, damit die Inhalte kurz nach dem Schreiben getestet werden. (Beachten Sie, dass dies nicht bedeutet, dass alle Tests selbst durchgeführt werden müssen.)
2. Verwenden Sie Feature-Toggles, entweder anstelle von Feature-Zweigen oder zusätzlich zu diesen. Mit den Funktionsumschaltern können Sie ein defektes Feature deaktivieren, ohne zu versuchen, es aus dem Code zu entfernen, damit Sie die anderen Features testen und freigeben können. Die Art von Umschalter, über die ich spreche, ist für Kunden nicht zugänglich. Sie möchten nicht, dass eine exponentiell steigende Anzahl von Kombinationen getestet wird. Sie stellen die Umschalter im QA-Zweig so ein, dass sie mit den Features übereinstimmen, die Sie freigeben möchten. Wenn sich der Plan ändert, weil ein Feature nicht bereit ist, ändern Sie diesen Umschalter.

Eine sehr einfache Lösung, die ich in einem etwas größeren Team als Ihrem gesehen habe, besteht darin, dass alle von einem einzigen Zweig aus arbeiten und bereitstellen.

Sie sagen, das Team ist agil, aber es ist nicht klar, ob Sie in Sprints (z. B. Scrum) oder in einem kontinuierlicheren Flow-Ansatz (z. B. Kanban) arbeiten. Angenommen, Sie machen Sprints, ist es das Ziel des Teams, den Code am Ende jedes Sprints für Ihre 14-tägige Veröffentlichung freizugeben. Es gibt keine Verwirrung darüber, ob ein Feature ein anderes kaputt macht, da sie alle zusammen entwickelt wurden. Tester können möglicherweise in kleineren Blöcken auf Funktionen zugreifen, da der Aufwand für Entwickler geringer ist. Und Sie brauchen nicht wirklich ein QA-Freeze, sondern jeder weiß, wann das Ende des Sprints ist und sollte keine Arbeit übernehmen, die er nicht beenden kann, oder in einem bereitstellbaren (dh deaktivierten) Zustand belassen.

Offensichtlich gibt es Vor- und Nachteile für jeden Ansatz. Ich präsentiere dies als eine Option, die nicht unbedingt der „beste Weg“ ist.

Der Grund, warum Sie diese Probleme bekommen, ist, dass Ihr Code, der für die Qualitätssicherung freigegeben wurde, nicht gut genug ist (und jeder?!). Sie müssen also eine bessere Version für die Qualitätssicherung erhalten, damit sie nicht so oft Bigfixes erhalten müssen. Der einfachste Weg, dies zu tun, besteht darin, einen Zwischenzweig einzuführen, für den Sie freigeben (nennen wir es Test). Dies ist immer noch im Entwicklungsbereich, aber es ermöglicht Entwicklern, darauf zu drängen, um weiter zu arbeiten, und verfügt gleichzeitig über eine integrierte Niederlassung, deren Qualität gut genug sein sollte, um an die Qualitätssicherung gesendet zu werden.

In diesem Zweig können Integrationstests durchgeführt werden, um die Fehler zu finden, die die Qualitätssicherung derzeit findet. Fehler können im ursprünglichen Zweig behoben und dann wieder zusammengeführt werden, bis rechts oder Fehler direkt in diesem Zweig behoben werden können (ich empfehle die ehemalige). Sobald es eine Menge grundlegender Tests bestanden hat, kann es an die Qualitätssicherung gesendet werden, um die "klebrigen Finger des Benutzers und das, was sie getan haben?" Zu erhalten. testen.

Dieser Ansatz soll den QS-Zweig vor fehlerhaften Entwicklungsfunktionen schützen - ob dies daran liegt, dass die Funktion nicht gut genug codiert wurde oder ob unerwartete Integrationsprobleme aufgetreten sind, spielt keine Rolle. Nur Entwicklerzweige, die die Integrationstests bestehen, werden zur Qualitätssicherung befördert.