Was passiert, wenn ein in Develop zusammengeführtes Feature vom Management verschoben wird?

53

Wir hatten kürzlich ein Problem, bei dem eine Funktion für unsere Webanwendung (automatische Anmeldung) vom Management verschoben wurde, weil sie den Start für zu "kalt" hielten, aber sie wollten, dass alle anderen Funktionen, an denen wir gearbeitet hatten, live gehen.

Das Problem ist, dass diese Funktionalität zusammen mit all den anderen Funktionen, die wir beim nächsten Release erwarteten, in die Entwicklung integriert wurden, sodass wir nicht einfach dev -> test -> master zusammenführen konnten, wie wir es normalerweise tun.

Wie hätten wir dieses Problem vermeiden können?

project-management git gitflow

— Steve
quelle

Je nachdem, wie Sie das lösen möchten, ist diese Frage für den Arbeitsplatz besser geeignet, wenn Sie keine technische Lösung suchen.

— Malavos

74

Ein Ansatz ist das Kennzeichnen von Merkmalen. Es kann sich in der Codebasis befinden, aber durch Konfiguration deaktiviert werden.

Eine weitere Option ist das Ausführen eines Revert-Commits, bei dem die Feature-Zusammenführung rückgängig gemacht wird, sodass sie nicht mehr entwickelt wird. Es kann eine neue Verzweigung erstellt werden, die die Zurücksetzung rückgängig macht und aussteht, um später zusammengeführt zu werden. Wenn Sie Github-Pull-Anforderungen verwenden, können Sie dies problemlos mit der Schaltfläche "Zusammenführen rückgängig machen" für eine zusammengeführte Pull-Anforderung tun.

— Daenyth
quelle

9

Bedeutet das Kennzeichnen der Konfiguration nicht eine Verdoppelung des Testaufwands für diesen Code? Sie müssen beide Pfade testen .

16

In diesem Fall können Sie, da Sie dieses Flag in der Produktion nicht aktivieren werden, den Off-Fall jetzt für die Veröffentlichung testen und dann den On-Fall testen, wenn er für die Produktion bereit ist. Das sollte ungefähr die gleiche Arbeit sein wie das Testen eines Zurücksetzens und erneuten Festschreibens.

— Alan Shutko

4

Der gebräuchliche Begriff ist Feature Toggle . Wenn es einen kleinen "Feature-Einstiegspunkt" gibt, kann dies wahrscheinlich nach der Verwaltungsentscheidung erfolgen. Wenn nicht, wird man sowohl mit dieser als auch mit jeder anderen Methode Probleme bekommen.

— Doc Brown

3

Wir haben Funktionen, die seit mehr als 6 Monaten in der Entwicklung sind und von Feature TogglingDoc Brown versteckt werden . Auf diese Weise können wir das Feature (oder dessen Fehlen) auch in nicht produktiven Umgebungen testen. Manchmal werden diese Funktionen zu vorhandenen Funktionen hinzugefügt. In diesem Fall sollten Unit-Tests sowohl für die alten als auch für die neuen Funktionen durchgeführt werden. Bei jedem Komponententest wird nur das Flag auf das gesetzt, was für den aktuellen Test erforderlich ist.

— ps2goat

25

Wie hätten wir dieses Problem vermeiden können?

Stellen Sie aus Prozesssicht Folgendes fest:

Wer war der Entscheider für diese Arbeit?
Warum hat sich die Entscheidung, diese Funktion freizugeben, geändert?
- Erwartungen nicht erfüllt?
- Missverständnisse?
- Unzureichende Geschäftsunterstützung?
- Keine Kundenbeteiligung?

Höchstwahrscheinlich gab es unterwegs Unterbrechungen der Kommunikation. Dies ist wichtig, denn wenn dies nicht funktioniert, basieren Ihre Entwicklungsprozesse auf einem falschen und falschen Verständnis der Geschäftsanforderungen.

— Enderland
quelle

9

+10. Sobald das Management anfing, Zweifel an der Freigabe des Features zu hegen, hätte es die Entwickler informieren müssen, damit die mögliche Entfernung bei der Entscheidung, das Feature in Develop zusammenzuführen, berücksichtigt werden konnte.

— Bart van Ingen Schenau

14

Dies ist keine sehr konstruktive Antwort - manchmal laufen die Dinge aus den verschiedensten Gründen seitwärts. Sicher, herauszufinden, dass es nicht früher als später zusammengeführt werden sollte, ist wichtig, aber das bedeutet nicht, dass ein Feature in letzter Minute entfernt wird. Vielleicht Vertragsänderungen, vielleicht zahlt Ihr Kunde nicht, vielleicht treten rechtliche Probleme auf. Sie müssen das Problem noch lösen, anstatt die Schuld

— zuzuweisen

11

Wenn es in Ihrer Organisation Personen gibt, die mächtig genug sind, um Fehler nicht zuzugeben, und die auch kindisch genug sind, um Fehler nicht zu vermeiden, sollten Sie zu Ihrer eigenen Information weiterhin Obduktionsprobleme haben. Sie wollen es ihnen nur nicht sagen (oder es zu explizit aufschreiben). Das heißt, Enderland verwendet nicht das Wort "Schuld", und wenn die Organisation diesen Rat als "herausfinden, wer die Schuld trägt" interpretiert, ist dies an sich ein Problem für die Organisation, daran zu arbeiten. Alles, was dies besagt, ist "Verstehe, warum das Problem aufgetreten ist", was wesentlich ist, um es in Zukunft zu vermeiden.

— Steve Jessop

2

Ich stimme voll und ganz zu, dies ist ein Management-Fehler, kein Entwickler-Fehler.

— Durron597

3

@enderland Mein Punkt ist, dass Sie einige Probleme nicht vermeiden können, also müssen Sie überlegen, wie Sie die Situation reparieren können. Hoffentlich werden Sie nicht so oft weit kommen, aber es wird früher oder später passieren, also planen Sie entsprechend.

— gbjbaanb

19

Vergessen Sie für einen Moment das Problem mit Ihrem Management und stellen Sie sich vor, Sie hätten die "automatische Anmeldefunktion" bereits in Ihrer neuesten Produktionsversion, die tief in Ihre Codebasis integriert ist. Jetzt erhalten Sie die neue Anforderung, einen "Aus-Schalter" für "automatische Anmeldung" hinzuzufügen. Wie würden Sie in Ihrem Git-Workflow damit umgehen?

Ich vermute, Sie würden "Deaktivieren der automatischen Anmeldung durch Konfiguration" einfach als zusätzliche Funktion deklarieren (dies ist nur eine Form der Funktionsumschaltung ), sodass sich diese Funktion problemlos in Ihren Workflow integrieren lässt. Sie können den Aufwand abschätzen, wenn Sie einen Feature-Zweig dafür verwenden möchten (oder nicht, wenn Sie für solche Probleme keinen Feature-Zweig verwenden). Und Sie können definitiv den von Ihnen beschriebenen üblichen "merge dev -> test -> master" -Fluss verwenden.

Und genau so können Sie in Ihrer aktuellen Situation damit umgehen. Aus Sicht des Git-Workflows sollte es keine Rolle spielen, ob die Änderungsanforderung vom Management für Release 1.0 stammt oder ob die Änderungsanforderung ein neuer Kundenwunsch für Release 2.0 ist.

— Doc Brown
quelle

Fowler hat einige wirklich gute Ausgaben, aber ich kann diese Methode zur Einführung von Funktionen nicht unterstützen. Der koordinierte Aufwand für solche Schalter erscheint als unnötige Belastung. Ich kann das Hinzufügen von Feature-Umschaltern unterstützen, um Features nach dem Zusammenführen zu entfernen, aber das Einfügen eines Switches als Teil der Anforderung macht mich unwohl.

— Gusdor

@Gusdor: siehe mein edit.

— Doc Brown

1

Dies ist genau das Problem, das ich mit Gitflow und GitHub Flow habe, und es scheint, dass dies bei Webanwendungen häufig vorkommt - oder eher der Norm entspricht. Es scheint, als würden Sie dieses Problem entweder rückwirkend (siehe oben) oder proaktiv (siehe unten) lösen.

Ich habe zusätzlich zu den Standard-Gitflow-Zweigen 'Bundle-Zweige' erstellt. Das Bundle enthält alle Funktionen, die für uat / qa bereit sind. Eine Liste der uat / qa-Funktionen wird erstellt. Diese werden zum temporären Bundle zusammengeführt und dieses Bundle wird in uat / qa bereitgestellt. Alle Fehlerkorrekturen finden im ursprünglichen Feature-Zweig statt und werden erneut in das Bundle integriert und bereitgestellt. Dies trennt die kommende Version und ermöglicht es, diese Funktionen gemeinsam zu testen, bevor sie in den Entwicklungszweig gelangen. Die zugelassenen Filialen erhalten eine Pull-Anfrage für die Entwicklung - nach dem Gitflow-Prozess. Testbereite Funktionen können dem temporären Bundle-Zweig hinzugefügt oder daraus entfernt und erneut bereitgestellt werden.

Dies sorgt dafür, dass der Master immer den produktionsbereiten Zustand widerspiegelt (kann mit Hook automatisiert werden).
Bei der Entwicklung wird immer der aktuellste (und getestete) Release-Kandidat berücksichtigt

Zu den Nachteilen gehören das Verwalten der Bundle-Liste und das Hinzufügen eines anderen Branch-Typs. Abgesehen von dem Retro-Fix, den ich für zu spät halte, scheint dies die praktikablere Lösung zu sein.

Mit einem GUI-Addon ist es möglicherweise optimal, Feature-Zweige pro Bundle-Bereitstellung zu aktivieren - unter Berücksichtigung der Automatisierung.

— David Latty
quelle