Einwöchiger Release-Zyklus: Wie mache ich das möglich?

In meinem Unternehmen (3 Jahre altes Startup der Webbranche) haben wir häufig Probleme mit dem Produktteam, das sagt: "aaaah, das ist jetzt ein Krisen-Patch!" (Nicht jeder?)

Dies hat Auswirkungen auf die Produktivität (und die Arbeitsmoral) des technischen Personals, einschließlich des Personals. Das Management hat eine Weile darüber nachgedacht, wie die Häufigkeit dieser Anfragen am selben Tag verringert werden kann, und hat die Lösung gefunden, die wöchentlich veröffentlicht wird. (Früher hatten wir alle zwei Wochen eine gemacht, was normalerweise ein paar Tage oder so verging.)

Es gibt 13 Entwickler und 6 lokale / 9 Offshore-Tester; Die Theorie besagt, dass nur 4 Entwickler (und alle Tester) an geradzahligen Releases arbeiten werden, es sei denn, es kommt eine Arbeit zustande, die wirklich spezifisches Fachwissen von einem der anderen Entwickler erfordert. Jeder Zyklus enthält zwei Tage Entwicklungsarbeit und zwei Tage QS-Arbeit (plus 1 Tag Scoping / Triage / ...).

Meine Fragen sind:

(a) Hat jemand Erfahrung mit dieser Länge des Release-Zyklus?

(b) Hat jemand davon gehört, dass dieser Release-Zyklus überhaupt versucht wurde?

(c) Wenn (a) oder (b), wie um alles in der Welt bringen Sie es zum Laufen? (Zu vermeidende Fallstricke usw. sind ebenfalls willkommen.)

(d) Wie können wir den Schaden minimieren, wenn dieser Versuch fehlschlägt?

Sie können sicherlich jede Woche liefern - oder sogar noch häufiger. Momentan veröffentlichen wir in der Regel alle zwei Wochen, aber es ist nicht ungewöhnlich, Funktionen bereitzustellen, wenn etwas ohne Benachrichtigung eines unserer Partner eingetroffen ist, das irrelevant wäre, wenn wir auf den nächsten Zyklus warten würden. Irgendwann in den nächsten Monaten möchte ich, dass wir zur kontinuierlichen Zustellung übergehen (Artikel werden veröffentlicht, sobald sie "fertig" sind, sobald dies praktisch ist), aber wir sind noch nicht zuversichtlich genug, dies zu tun weit.

Entscheidend ist, dass Ihre Website durch automatisierte Tests stark abgedeckt ist - sowohl Unit-Tests als auch End-to-End-Akzeptanztests / ausführbare Spezifikationen. Implizit bedeutet dies auch, dass Ihr Build vollständig automatisiert ist. Auf der Akzeptanzebene verwenden wir Robot Framework, das sich dank seines Keyword-Ansatzes hervorragend für den schnellen Aufbau einer wartbaren Testsuite eignet. Unser Vor-Ort-Tester prüft das Aussehen und Verhalten vor Ort auf Fehler, aber wir haben auch ein paar Leute in Indien, die eine gründlichere Prüfung in verschiedenen Browsern durchführen (es gibt Websites, die Ihnen dabei helfen, indem sie Screenshots für Sie machen, z. B. BrowserLab) ).

Wir automatisieren die Bereitstellung nicht vollständig (der letzte Schritt erfordert ein manuelles Eingreifen, dies ist eine bewusste Entscheidung für uns) - aber wir automatisieren alle Dinge wie die Sicherstellung, dass die richtigen Datenbankverbindungen verwendet werden, usw. mit kurzen Bereitstellungszyklen es wäre zu leicht, mit so etwas einen Fehler zu machen.

Es gibt ein ziemlich gutes aktuelles Buch über kontinuierliche Lieferung, das Sie vielleicht lesen möchten. Ich habe es überflogen, aber noch nicht im Detail durchgearbeitet. Was ich bisher gelesen habe, stimmt jedoch mit unseren Erfahrungen überein: Kontinuierliche Bereitstellung: Zuverlässige Softwareversionen durch Build-, Test- und Bereitstellungsautomatisierung

Zusammenfassend benötigt man ein hochdiszipliniertes Team, einen hohen Automatisierungsgrad und vor allem ein extrem hohes Maß an Vertrauen in diese Automatisierung. Für mich scheint es ein Fehler zu sein, zu wöchentlichen Zyklen überzugehen - Krisenpatches weisen auf andere Probleme hin, und Sie sollten daran arbeiten, diese zu beseitigen. Eine Erhöhung des Tempos könnte die Situation möglicherweise verschlimmern ...

Wenn Sie sich ständig im "Crisis Release" -Modus befinden, ist es empfehlenswerter, einen Schritt zurückzutreten und Ihren Code und Ihren Prozess neu zu bewerten. Offensichtlich gibt es dort eine Art Fehler, der sich immer wieder wiederholt.

Möglicherweise ist dies nicht in vollem Umfang im Produktionsmaßstab möglich, aber es lohnt sich wahrscheinlich, mindestens ein hochrangiges Mitglied und eine andere Untergruppe von Entwicklern und Testern dieser Bewertung zu widmen.

Der "4 auf einmal Ansatz" klingt für mich nicht nach einem klaren Gewinner. Das bedeutet ständiges Umschalten des Kontexts, was eine weitaus geringere Effizienz bedeutet.

Denken Sie daran, dass Sie, wenn Sie sich ständig beeilen, Änderungen vorzunehmen, mit größerer Wahrscheinlichkeit Fehler bei diesen Änderungen machen und dabei etwas anderes kaputt machen.

Release-Zyklen von weniger als einer Woche wurden in der Software-Branche sicherlich erreicht. Sie verwenden die Technik der kontinuierlichen Bereitstellung (auch kontinuierliche Bereitstellung genannt ).

Es gibt ein Unternehmen, das 50 Mal am Tag veröffentlicht. Dieser Blog-Beitrag beschreibt, wie sie es tun .

Das Management hat eine Weile darüber nachgedacht, wie die Häufigkeit dieser "Krisenjobs" verringert werden kann, und hat die Lösung gefunden, die wir jede Woche veröffentlichen werden.

Sieht so aus, als wären Sie Weltmeister. Warum nicht in Ihren Teamgeist investieren? Sie werden sehen, dass die Probleme von selbst verschwinden werden.

(a) + (b) IMHO, je nach Größe Ihres Teams sollten es maximal zwei Wochen sein. Eine Woche wird für Ein-Mann-Shows oder sehr kleine Teams (wie 2 oder 3) funktionieren.

(c) + (d) Unabhängig von der Größe Ihres Teams oder Projekts ist eines der ersten Dinge, die ich tue, die Automatisierung der Erstellung und Bereitstellung. Ich spare Tage, wenn nicht Wochen Arbeit, indem ich das in den frühen Tagen eines Projekts mache.

Ihre Bereitstellungen müssen mit einem Klick durchgeführt werden. Von der Quelle zur Inszenierung, dann von der Inszenierung zur Produktion. Dafür gibt es viele Tools. Von Ant / Nant bis zu superschweren Sachen wie Automated Build Studio .

Von der Bereitstellung von Dateien bis zum Datenbank-Upgrade kann alles automatisiert werden, einschließlich Backups, Benachrichtigungen, Berichterstellung usw.