Frage zur Bereitstellung - Wie behandelt man fehlerhafte Tickets während der Bereitstellung?

Question

(Webprojekt) Hallo, ich benutze ein User Stories/Tickets während der Entwicklung. Wir benutzen auch Sprints (Scrum). So wird ein Feature in einem Ticket beschrieben. Am Ende des Sprints werden wir uns also umsehen. Nach der Überprüfung haben wir einige Tickets beendet und einige sind fehlgeschlagen. Ich bin sehr gespannt, wie ich nur die fertigen Tickets/Features bereitstellen kann.

Ich dachte über die Erstellung eines Zweigs pro Ticket mit GIT nach. Und dann nur fertige Tickets/Filialen zu einer Eltern-Filiale zusammenführen.

weitere Ideen?

Answer 1

Ich denke, jeder Prozess, den Sie verwenden, erfordert etwas Flexibilität.

Wenn Sie Zweigzweige für jedes Ticket verwenden, können Sie festlegen, dass keine, die eindeutig unvollständig sind, am Ende dieses Sprints wieder in Ihren Hauptzweig eingefügt werden. Leider verhindert dies häufiges Zusammenführen und Sie haben wahrscheinlicher erhebliche Zusammenführungskonflikte, da jeder versucht, Änderungen am Ende eines Sprints zusammenzuführen anstatt sie zu beenden, was anderen die Chance geben würde, diese Änderungen in ihren Verlauf zu rebasen. Sie müssen außerdem sicherstellen, dass die resultierende Zusammenführung aller dieser Features auch dann getestet wird, wenn jedes Feature unabhängig voneinander abgeschlossen ist.

Wenn Sie häufig zusammenführen, dann können Sie nicht einfach nur die Änderungen auswählen, die die Überprüfung im Nachhinein durchlaufen. Sie können jedoch ein Muster aus der fortlaufenden Bereitstellung übernehmen und neue Funktionen erstellen, die Sie in Ihren Releases aktivieren und deaktivieren können. Codeänderungen können sich im Hauptzweig befinden, Sie müssen jedoch nicht unbedingt neue Features verfügbar machen, bis sie als bereit gelten. Offensichtlich hat dies einige Gemeinkosten und ist nur für bestimmte Arten von Änderungen sinnvoll.

Schließlich könnten Sie versuchen, alle Ihre Nacharbeiten am Ende eines Sprints zu vermeiden. Wenn Sie mindestens ein paar Entwickler dazu bringen können, ein Feature zu überarbeiten, bevor Sie es in Ihren Hauptzweig integrieren und anständige Tests durchführen, sollten Sie in der Lage sein, die Qualität Ihrer Hauptzweige hoch zu halten, ohne einen Engpass zu verursachen.

Hoffentlich finden Sie etwas, das für Sie arbeitet.

Answer 2

Ich dachte über das Erstellen einer Verzweigung pro Ticket mit GIT nach. Und dann nur fertige Tickets/Filialen zu einer Eltern-Filiale zusammenführen. weitere Ideen?

Dieser Ansatz, obwohl sauber, würden wir einen Schmerz für Wartung und Zusammenführung. Und was, wenn alle Tickets auf ihrer eigenen Filiale funktionieren und nicht, wenn sie mit dem Trunk zusammengeführt werden?

Meine Vorschläge: 1. Wenn Sie separate Zweigstelle pro Ticket erstellen, führen Sie die QA zum Integrationstest durch. 2. Wenn Sie separate Verzweigungen pro Ticket erstellen, stellen Sie sicher, dass die Sprint-Benutzergeschichten unabhängig genug sind, damit sie nach der Zusammenführung nicht fehlschlagen.

1. Können Sie Svn verwenden? Mit svn würde jedes Einchecken ein Tag des Quellcodes erzeugen. svn revert würde Änderungen für einen bestimmten Check-in, der sich auf ein bestimmtes Ticket bezieht, zurücksetzen. Ich bin mir nicht sicher, ob das in GIT möglich ist.

2. Versuchen Sie, eine Verzögerung zwischen Ihren Sprints und den Releases zu halten. Für z. Sprints, an denen Sie gerade arbeiten, könnten zwei Wochen später bereitgestellt werden, sodass Sie genügend Zeit haben, um das Zusammenführen, Umkehren oder Planen durchzuführen.