Wir beginnen mit zunehmender Größe auf ein Problem zu stoßen, bei dem Features zum Testen bereitgestellt werden, aber bis alles getestet ist und genehmigte neue Features zum Testen bereitgestellt werden.

Dies schafft eine Umgebung, in der wir fast nie auf die Produktion drängen können, da wir eine Kombination aus getesteten und nicht getesteten Funktionen haben. Ich bin mir sicher, dass dies ein häufiges Problem ist, aber ich habe noch keine guten Ressourcen für uns gefunden.

Einige Besonderheiten:

• GIT auf BitBucket
• Jenkins für die Skriptbereitstellung in Azure

Was ich mir erhoffe, ist eine Möglichkeit, Features zu isolieren, während sie sich durch Umgebungen bewegen, und nur das zu pushen, was bereit ist, zu produzieren.

Es hört sich so an, als hätten Sie hier ein paar Probleme:

1. Identifizieren von Funktionen für eine bestimmte Version

Dies ist ein Projektmanagement- und ein Koordinationsproblem. Wird diese Funktion vor, zur gleichen Zeit oder nach dieser anderen Funktion veröffentlicht? Wenn Releases jeweils für ein Feature durchgeführt werden sollen, geben Sie dies an. Wenn Features in Releases gruppiert werden sollen, ermitteln Sie die Gruppierungen und erzwingen Sie sie mit den Entwicklern und Entscheidungsträgern durch. Verwenden Sie Ihr Issue-Tracking- oder Ticketing-System, um Releases zu kennzeichnen. Stellen Sie klar, dass alle von ihnen ein No-Go-Feature einer bestimmten Version sind.

2. Verzweigungsstrategien

Git-Flow ist die einfache Antwort auf solche Probleme. Oft wird eine Variante von Git-Flow verwendet, auch wenn man nicht weiß, was es ist. Ich werde nicht sagen, dass es ein Allheilmittel für alle Probleme ist, aber es hilft sehr.

Es hört sich so an, als stoßen Sie auf ein Problem mit nicht-deterministischen Release-Strategien, bei denen Features als Scattershot eingestuft werden und etwas, das vor langer Zeit mit der Entwicklung begonnen hat, möglicherweise nach etwas veröffentlicht wird, das in jüngerer Zeit begonnen hat - leap-frog-Features.

Langlebige Feature-Zweige oder Zweige mit gleichzeitiger Veröffentlichung sind wahrscheinlich die beste Antwort auf diese Art von Problemen. Führen Sie das Neueste von Master in Ihren langjährigen Filialen zusammen (oder bündeln Sie es, wenn Sie damit vertraut sind) . Achten Sie darauf, nur Features zusammenzuführen, die bereits aktiv sind, da Sie sonst auf die Probleme stoßen, die Sie jetzt haben (zu viele vermischte Features in einem Zweig).

"Hotfix" - oder "Bugfix" -Zweige sind ein wesentlicher Bestandteil dieses Prozesses. Verwenden Sie sie für kleine, einmalige Korrekturen mit einem kurzen QS-Zyklus.

Ihrer Beschreibung nach ist es möglicherweise sogar besser, keinen offiziellen Entwicklungszweig zu unterhalten. Verzweigen Sie stattdessen alle Features vom Master und erstellen Sie zusammengeführte Release-Zweige, sobald ein Release identifiziert wurde.

3. Umgebungen

Ordnen Sie Git-Zweige nicht Ihren Umgebungen zu, mit Ausnahme von Production == Master. Der Zweig "Entwicklung" sollte als gebrochen angenommen werden. Release-Zweige werden an Testumgebungen weitergeleitet, unabhängig davon, ob es sich um eine QS-Umgebung oder eine Staging-Umgebung handelt. Wenn nötig, verschieben Sie einen bestimmten Feature-Zweig in eine Umgebung.

Wenn Sie mehr als einen Feature-Zweig haben, der separat freigegeben werden muss, aber gleichzeitig getestet wird ..... ¯ \ _ (ツ) _ / ¯ .... einen anderen Server hochfahren? Führen Sie sie möglicherweise zu einem Wegwerfzweig zusammen. Übernehmen Sie Korrekturen / Änderungen an den ursprünglichen Zweigen und führen Sie sie erneut zum Wegwerfzweig zusammen. Führen Sie die endgültige Genehmigung und UAT für einzelne Release-Zweige durch.

4. Entfernen von nicht genehmigten Features aus einer Zweigstelle

Dies ist, was die obigen Gedanken zu vermeiden versuchen, denn dies ist zweifellos die schmerzhafteste Sache, die zu versuchen und zu tun ist. Wenn Sie Glück haben, wurden Features mithilfe von Merge-Commits atomar in Ihre Entwicklungs- oder Testzweige integriert. Wenn Sie Pech haben, haben sich Entwickler direkt an die Entwicklungs- / Testbranche gewandt.

Wenn Sie sich auf ein Release vorbereiten und nicht genehmigte Änderungen haben, müssen Sie Git verwenden, um diese nicht genehmigten Commits aus dem Release-Zweig zu entfernen. Die beste Idee ist, dies vor dem Testen der Version zu tun .

Viel Glück.

Hier ist eine Idee: Verwenden Sie keine Release-Zweige mehr. Beginnen Sie stattdessen mit dem Einrichten von Funktionsumschaltungen und verwalten Sie diese über die Konfiguration. Auf diese Weise werden Feature-Zweige immer in Master zusammengeführt, und es sollte nie eine Frage darüber bestehen, welche Version sich in Test oder Produkt befindet. Wenn Sie eine Frage dazu haben, welche Funktionen / Implementierungen in einer Umgebung aktiv sind, überprüfen Sie einfach die Konfigurationsdatei.

Dies sollte eine einfache Sache der Koordination zwischen Test und Produktion sein. Wenn Sie in Git Feature-Zweige verwenden, beenden Sie einfach das Pushen abgeschlossener Feature-Zweige zu Test während eines Testzyklus und setzen Sie den Test fort, wenn der Test abgeschlossen ist.

Wenn Sie eine bessere Kontrolle benötigen, trennen Sie Test in einen Entwicklungsserver und einen Abnahmetestserver und koordinieren Sie die Zweige, die auf den Abnahmetestserver übertragen werden, mit dem Testteam. Jemand kann dann für den Start der endgültigen Bereitstellung vom Abnahmetest zur Produktion verantwortlich sein.

Arbeit stapelt sich

Dies ist nach meiner Erfahrung ein universelles Problem. Ich adressiere es mit:

• Starkes Management von Feature Releases durch den Product Owner
• Stellen Sie sicher, dass Zweige beim Zusammenführen gelöscht werden
• Limit work in progress (mit Spaltenlimits in Jira)
• Vierteljährliche Überprüfung von alten Tickets, die sowohl Fehler als auch Funktionen aufweisen
• Rückblicke, um die Komponenten des Problems zu diskutieren
• Ständige Ermutigung für Code-Überprüfungen von allen
• Kombinieren Sie Möglichkeiten, um langjährige Tickets und Probleme zu lösen
• Vierteljährliche Besprechungen, um alte Tickets zu überprüfen und zu bereinigen
• Teamansatz, um Entwickler, Produkt und QA / QE eng zusammen zu bringen
• Gute Berichte und Tools, um neue Produktfunktionen und den Rückstand offensichtlich zu machen
• Überprüfen Sie die Sitzungen, um alte Zweige zu durchsuchen und zu löschen

Geäst

Sie benötigen einige Zweige, um diesen Prozess zu steuern:

• Besonderheit : Diese Zweige werden vom Meister geboren. Verwenden Sie eine Projektverwaltungsanwendung, um jeden Feature-Zweig mit einer Aufgabe zu identifizieren. Per Beispiel, wenn Sie TRAC verwenden, werden Sie enden , wenn Branchen wie: 1234-user-crud, 1235-bug-delete-catalogetc. mit der Task - Nummer Identifizieren Sie Ihre Commits Auch dies wird Ihnen helfen , eine Menge , wenn Sie Probleme beim Zusammenführen haben (Sie werden).
• test : Alle ausgeführten Feature-Zweige werden zum Testzweig zusammengeführt. Sie führen den Testzweig niemals in einem Feature-Zweig zusammen , da Sie keinen Code von anderen Features wünschen, die nicht in der Produktion (Master) enthalten sind. Gleiches gilt für die releaseFiliale.
• release : Wenn Sie entscheiden, welche getesteten Features in der Produktion vorhanden sein sollen, führen Sie diese Zweige (wieder ...) in diesem Zweig zusammen. Sie müssen alle Funktionen erneut testen, da diese Zusammenführung neue Probleme verursachen kann. Wenn das Release getestet und abgeschlossen ist, führen Sie diesen Zweig zum Master zusammen und erstellen ein Tag auf dem Master für die Version.
• Master : Enthält nur den Seriencode.

Siehe den Git Flow:

                              |FEAT_2|
                                  |
                             .---C06<-------.---------.
                            /                \         \
                           /   |FEAT_1|        \         \
                          /       |            \         \
                         /    .--C07<--.--------\---------\---------.
                        /    /          \        \  |TEST| \         \
                       /    /            \        \    |    \         \
                      /    /        .-----`--C09<--`--C10    \         \ |RELEASE|
                     /    /        /                          \         \    |
    <v4.6.0>        /    /        /                       .----`--C11<---`--C12<--.
       |           /    /        /                       /                         \
C01<--C02<--C04<--´----´--------´-----------------------´---------------------------`--C13
 |           |                                                                          |
<v4.5.0>  <v4.6.1>                                                                   |MASTER|
                                                                                        |
                                                                                     <v4.7.0>

Umgebungen

Sehr einfach:

• test : In dieser Umgebung wird der Testzweig verwendet.
• release : In dieser Umgebung wird der aktuelle Release-Zweig verwendet.

Die Entwickler arbeiten in seiner Maschine, wobei jeder seine eigene Datenbank verwendet. Wenn es nicht möglich ist, dass jeder Entwickler eine eigene Datenbank hat (aufgrund von Lizenzen, Größe der Datenbank usw.), werden Sie viele Probleme haben, eine Datenbank zwischen den Entwicklern zu teilen: Wenn jemand eine Spalte oder eine Tabelle in seiner Filiale löscht, die anderen Zweige zählen immer noch mit dieser Spalte / Tabelle in der Datenbank.

Probleme

Das größte Problem in diesem Prozess ist die Zusammenführung.

Sie müssen die gleichen Zusammenführungen in testund neu erstellen release. Dies ist schmerzhaft, wenn im Code einige gute Änderungen vorgenommen werden, z. B. Löschen einer Klasse, Verschieben / Umbenennen von Methoden usw. Da Sie keinen Code aus einem test(oder release) Zweig in einen Feature-Zweig abrufen können, können die Zusammenführungszusagen nur in aufgelöst werden das test(oder release). Sie lösen also dieselben Konflikte in zwei verschiedenen Zweigen und produzieren wahrscheinlich bei jeder Zusammenführung unterschiedlichen Code. In Zukunft werden Sie feststellen, dass das Testteam die Funktionen zweimal testen muss: in den Zweigen testund release, weil bei jeder Zusammenführung kann zu verschiedenen Fehlern führen.

Ein weiteres Problem ist der testZweig. Sie müssen diesen Zweig mastervon Zeit zu Zeit "recyceln" (löschen und einen neuen von erstellen ), da einige alte Zweige (oder alte Zusammenführungen, zusammengeführte Zweige, die gelöscht wurden) dem neuen Code eine Menge Probleme bereiten können. viel von dem abweichen, was drin ist master. In diesem Moment müssen Sie die Kontrolle darüber haben, welche Zweige Sie erneut in der zusammenführen möchten test.

Die wirklich beste Lösung ist, dass das Business-Team weiß, was in der nächsten Version geliefert werden muss, und jeder in einer einzigartigen Niederlassung arbeitet (Niederlassung entwickeln). Es ist gut für sie, die Möglichkeit zu wählen, welche "Fertig" -Funktion sie in der nächsten Version haben möchten, wann immer sie wollen (ich denke, dies ist Ihr Szenario), aber dies ist ein Albtraum für die Entwickler und (ich glaube) für die Testteam.

Klingt wie Sie verschmelzen Änderungen aus der Integration Niederlassung in Ihre Produktionszweig, der meiner Meinung nach keine gute Praxis ist, genau aus den Gründen , die Sie erwähnen. Sobald ein Produktionszweig für ein bestimmtes Release aus dem Hauptintegrationszweig gezogen wird, kann der Integrationszweig jederzeit divergieren (schließlich soll er in das nächste Release übergehen). Das Zusammenführen des Integrationszweigs mit dem aktuellen Release-Zweig kann zu Änderungen führen, die mit diesem Release nicht kompatibel sind.

IMHO wäre ein richtiger Prozess:

• Ziehen Sie einen Produktionszweig nur dann aus dem Integrationszweig, wenn er dem gewünschten Qualitätsniveau nahe genug ist, sodass nur eine Handvoll Änderungen zu erwarten sind, um die Freigabe abzuschließen. Mit anderen Worten, die Fertigstellung des Features sollte (kontinuierlich) auf dem Integrationszweig bewertet werden, bevor der Produktionszweig gezogen wird.
• Nachdem der Produktionszweig abgerufen wurde, werden nur von Kirsche gepflückte Änderungen als eigenständige / punktgenaue Änderungen behandelt - dh es wird überprüft, ob sie tatsächlich wie erwartet funktionieren (nur weil eine Änderung in einem Zweig funktioniert, bedeutet dies nicht unbedingt, dass sie auch funktioniert in einem anderen Zweig).

Persönlich klingt dies so, als ob es sich eher um ein Prozessproblem als um ein Werkzeugproblem handeln könnte. Ein paar Dinge, die ich hier vorschlagen würde:

• Ich bin mir nicht sicher, ob Sie separate Entwickler- und QA-Gruppen haben. Wenn Sie dies tun, stellen Sie sicher, dass sowohl Dev als auch QA an den Sprintplanungs- und Schätzungsbesprechungen teilnehmen. In einem meiner vorherigen Unternehmen haben wir sichergestellt, dass die Anzahl der Story-Punkte, die wir einer Story zugewiesen haben, sowohl für den Entwicklungs- als auch für den Testaufwand verantwortlich ist. (Theoretisch könnten Sie auch zwei separate Schätzungen für den Entwicklungs- und den Qualitätssicherungsaufwand haben. In beiden Fällen muss Ihre Schätzung jedoch beide umfassen. Die für eine Story erforderliche Zeit ist die Zeit, die für die tatsächliche Bereitstellung erforderlich ist.) Auch wenn Sie keine separate QS-Gruppe haben, sollten Sie dennoch den Testaufwand in Ihre Schätzungen einbeziehen.
• Vereinbaren Sie im Voraus, wie viele Geschichten Sie in einen bestimmten Sprint mit einbeziehen möchten. Die Anzahl der Story-Punkte, die Sie akzeptieren, hängt von der Anzahl der Punkte ab, die Ihre Entwickler im Sprint erreichen können, und von der Anzahl der Punkte, die die Qualitätssicherung im Sprint testen kann. (Ich gehe natürlich davon aus, dass QA-Sprints hinter Dev-Sprints liegen, aber Sie können dies an Ihren Prozess anpassen.) Wenn Ihre Entwickler 200 Story-Punkte erledigen können, Ihre Qualitätssicherung jedoch nur 150 Story-Punkte erledigen kann, können Sie natürlich nur 150 Story-Punkte erledigen, bevor die Arbeit anfängt, sich anzuhäufen, und Sie erhalten einen Fall wie den, den Sie beschreiben. (In einem solchen Fall möchten Sie möglicherweise die Ursache der Straßensperre untersuchen, um sie zu beheben.)
• Niemand schiebt irgendetwas zur Qualitätssicherung, bis alles, was sich aktuell in der Qualitätssicherung befindet, getestet und ausgeliefert wurde .
• Eine vollständige Funktion wurde getestet und ausgeliefert. Wenn es nicht geliefert wird, wird es nicht gemacht.
• Natürlich möchten Sie versuchen, dies nach einem festen Zeitplan zu tun. Eine der Ideen hinter Continuous Integration und Agile ist die Iteration. Per Definition bedeutet Iteration eine häufige Übermittlung. Häufige Integrationen und Lieferungen minimieren das Risiko jedes einzelnen.

Ehrlich gesagt denke ich, das Wichtigste wird die Disziplin darüber sein, wann Sie liefern und wie viele Aufgaben Sie tatsächlich in einem bestimmten Zeitraum vollständig erledigen können.

Zusammenfassend: Liefern Sie nur an die Qualitätssicherung, wenn Sie mit dem Testen und Bereitstellen der alten Funktionen fertig sind.

Wenn "alles getestet und genehmigt" ist, implementieren Sie das, was getestet und für die Produktion genehmigt wurde. Dies könnte ein bestimmtes Commit oder ein von Jenkins erzeugtes Build-Artefakt sein.

Es sollte keine Rolle spielen, dass spätere Festschreibungen für denselben Zweig noch nicht getestet wurden.