In der Produktion sind "subtile" Fehler aufgetreten, die in der Staging-Umgebung nicht identifiziert wurden. In einem der Projekte mit solchen Problemen habe ich gesehen, dass dies durch eine Taktik, die ich als Doppelprobleme bezeichne, recht erfolgreich behoben wurde. Ich meine, für solche Bugs haben die Jungs zwei Tickets im Issue Tracker erstellt: eines wurde Entwicklern zugewiesen, um den Code zu reparieren, das andere Testern, um Regressionstests oder Änderungen in der Staging-Umgebung zu entwerfen und einzurichten, die verhindern würden, dass sie in Zukunft wiederholt werden. Das half, die Inszenierung nahe genug zu halten, um sie anzustacheln.
Bei Problemen in der Produktionsumgebung sind Rollbacks erforderlich. Wenn diese häufig auftreten, handelt es sich bei Ihren wöchentlichen Veröffentlichungen tatsächlich um Fälschungen. Passen Sie die Häufigkeit an die tatsächlich funktionierende Stufe an. Mit Fälschung meine ich, dass, wenn Sie sagen, eines von zwei Ihrer wöchentlichen Releases rückgängig machen, dies bedeutet, dass die Benutzer alle zwei Wochen mit einem neuen (funktionierenden) Release konfrontiert werden - das ist alles, was zählt, nicht die Anzahl der von Ihnen bereitgestellten Releases.
Begeisterte Feature-Verzweigungen - Bedeutet das, dass Sie vor einiger Zeit auch versucht haben, an einer einzelnen Verzweigung zu arbeiten, und diese als minderwertig eingestuft haben? Wenn ja, dann überspringen Sie den Rest. Andernfalls versuchen Sie, an einem einzelnen Zweig zu arbeiten (falls erforderlich, suchen Sie bei Google nach der Verzweigungsstrategie "Entwicklungszweig" oder nach der Verzweigungsstrategie "instabiler Trunk", um weitere Informationen zu erhalten). Wenn Sie Perforce verwenden, durchsuchen Sie das Web nach Microsoft-Richtlinien zum Verzweigen und Zusammenführen. Versuchen Sie, habe ich das gesagt? Es tut mir leid, ein passendes Wort sollte getestet werden : Ich meine, 1) Planen Sie, wann und wie zu messen ist, ob ein einzelner Zweig besser ist oder nicht, als einer, den Sie jetzt haben, und 2) Planen Sie, wann und wie Sie in diesem Fall zurück zu Feature-Zweigen wechseln Testen schlägt fehl .
PS.
Wahrscheinlich finden Sie weitere Tricks wie diese, wenn Sie im Web nach Risikomanagement für Softwareprojekte suchen
aktualisieren
<Kopie aus Kommentaren>
Ich empfinde häufige Hotfixes als Symptom für eine unterbrochene Testpipeline. Ist dies nicht der Fall? In jedem Fall sind wiederholte Veröffentlichungen erforderlich, damit die Hotfixes veröffentlicht werden und mehr Arbeit für das Ops-Team geleistet wird. Darüber hinaus werden Hotfixes normalerweise unter extremem Zeitdruck codiert, was bedeutet, dass sie wahrscheinlich von geringerer Qualität sind als normale Arbeit.
</ copy from comments>
- Last-Minute-Hotfixes - obige Bedenken erscheinen mir angemessen, ebenso wie Ihr Hinweis auf eine unterbrochene Test-Pipeline. Mit diesem Update klingt Ihre vorherige Notiz, dass die Integration von neuem Code am Montag blockiert ist, wie ein weiteres Symptom einer unterbrochenen Pipeline (ich denke, ein genaueres Wort wäre umstritten ). Mit Konflikt meine ich Folgendes: Sie verwenden einen einzelnen Zweig, um gleichzeitig zwei Zwecke zu erfüllen : Integration und Freigabe. Wenn sich die Freigabe nähert, geraten diese beiden Zwecke in Konflikt miteinander, was zu widersprüchlichen Anforderungen führt: Der Integrationszweck wird am besten mit einem kontinuierlich geöffneten Zweig ( Früh und häufig zusammenführen ) erfüllt, während die Freigabestabilität davon profitiert, dass der Zweig versiegelt wird(isoliert) so lange wie möglich. A-ha, es sieht so aus, als würden Puzzle-Teile zusammenpassen ...
Sehen Sie, dieses Einfrieren am Montag scheint nun ein Kompromiss zu sein, der zu widersprüchlichen Zwecken gemacht wurde: Entwickler leiden unter einer Blockade der neuen Code-Integration, während Tester unter einer zu kurzen Blockade leiden. Jeder ist etwas unglücklich, aber beide Zwecke werden mehr oder weniger erfüllt.
Wissen Sie, ich denke, Ihre beste Wahl wäre es, wenn Sie versuchen , von einem bestimmten Zweig (außer der Integration) freizugeben . Ob dieser Zweig langlebig ist wie die Integration oder kurzlebig wie Ihre Feature-Zweige (wobei "Feature" nun, Release ist) - es liegt an Ihnen, es muss nur getrennt sein.
Man denke nur daran. Momentan ist ein Tag nicht genug, um die Freisetzung bequem zu stabilisieren, oder? Mit der neuen Verzweigungsstrategie können Sie nur zwei Tage vor der Veröffentlichung eine Verzweigung vornehmen, kein Problem. Wenn Sie feststellen, dass nicht einmal zwei Tage ausreichen, versuchen Sie, 3 Tage vorher zu forken, usw. Sie können den Release-Zweig so früh wie gewünscht isolieren, da dies das Zusammenführen von neuem Code mit dem Integrationszweig nicht mehr blockiert. Beachten Sie, dass in diesem Modell der Integrationszweig überhaupt nicht eingefroren werden muss. Ihre Entwickler können ihn kontinuierlich am Montag, Dienstag und Freitag verwenden.
Der Preis, den Sie für dieses Glück bezahlen, ist die Komplikation von Hotfixes. Diese müssten statt in einem Zweig in zwei Zweigen zusammengeführt werden (Release + Integration). Darauf sollten Sie sich beim Testen eines neuen Modells konzentrieren. Verfolgen Sie alles, was damit zusammenhängt - zusätzlicher Aufwand für das Zusammenführen mit dem zweiten Zweig, Aufwand für das Risiko, dass das Zusammenführen mit dem zweiten Zweig vergessen wird - alles im Zusammenhang.
Fassen Sie am Ende des Tests einfach zusammen, was Sie aufgezeichnet haben, und erfahren Sie, ob die Menge dieses zusätzlichen Aufwands akzeptabel ist oder nicht. Wenn es akzeptabel ist, sind Sie fertig. Wechseln Sie andernfalls zu Ihrem aktuellen Modell, analysieren Sie, was schief gelaufen ist, und überlegen Sie, wie Sie sich noch verbessern können.
update2
<Kopie aus Kommentaren>
Mein Ziel ist es, Storys innerhalb einer Iteration (hinter oder vor einer Konfigurationswand) zu testen und bereitzustellen. Dies kann nur erreicht werden, wenn die Tester die in der Iteration durchgeführten Arbeiten testen (und nicht den Code aus der vorherigen Iteration stabilisieren).
</ copy from comments>
Aha. Nun, ich habe keine direkte Erfahrung mit dieser Methode, aber ich habe in einem Projekt, das mit unserer verwandt ist, erfolgreiche In -Iteration- Art-Tests gesehen . Da unser Projekt den umgekehrten Weg einschlug, hatte ich auch den Luxus, diese gegensätzlichen Ansätze von Angesicht zu Angesicht zu vergleichen .
Aus meiner Sicht sah der Testansatz außerhalb der Iteration in diesem Rennen überlegen aus. Ja, ihr Projekt ist gut gelaufen und ihre Tester haben Bugs schneller als unsere entdeckt, aber irgendwie hat das nicht geholfen. Unser Projekt lief auch gut, und irgendwie konnten wir uns kürzere Iterationen als sie leisten, und wir hatten weniger (viel weniger) verrutschte Veröffentlichungen als sie, und es gab weniger Spannungen zwischen Entwicklern und Testern an unserer Seite.
BTW trotz schnellere Erkennung an ihrer Seite konnten wir über die gleiche durchschnittliche Bug Lebensdauer (Lebensdauer ist die Zeit zwischen der Einführung und haben fix , nicht zwischen Einführung und Detektion). Wahrscheinlich hatten wir hier sogar einen kleinen Vorteil, da wir mit kürzeren Iterationen und weniger verrutschten Releases behaupten konnten, dass unsere Fixes Benutzer im Durchschnitt schneller erreichen als ihre.
Zusammenfassend glaube ich immer noch, dass die Isolierung der Release-Codeline bessere Chancen bietet, die Produktivität Ihres Teams zu verbessern.
auf einen weiteren Gedanken ...
- Die Isolation der Release-Codeline hat bessere Chancen - beim erneuten Lesen könnte dies den Eindruck erwecken, dass ich Sie davon abhalte, In-Iteration- Tests durchzuführen . Ich möchte klarstellen, dass ich es nicht tue.
In Ihrem Fall ist der Ansatz des In-Iteration-Testens sicher (äh ... Test ), da Sie offenbar ein klares Verständnis dafür haben, wie dies erreicht werden kann (glatte Test-Pipeline ) und welche Haupthindernisse bestehen. Und schließlich haben Sie immer die Möglichkeit, auf einen alternativen Ansatz zurückzugreifen, wenn Sie es zu schwierig finden, diese Pipeline richtig zu machen.
Übrigens in Bezug auf Hindernisse, weitere, die es in diesem Fall wert sind, im Auge behalten zu werden, sind Probleme wie das Versagen, einen Fehler auf der Seite des Entwicklers zu reproduzieren, und das verspätete Finden / Verspätete Überprüfen der Fehlerbehebung auf der Seite des Testers. Diese könnten auch Ihre Pipeline blockieren, wie dies jetzt bei Hotfixes der Fall ist.