Tygodniowy cykl wydawniczy: jak mogę to zrobić?

W mojej firmie (trzyletni start-up branży internetowej) często napotykamy problemy z zespołem produktu, który mówi „aaaaa, teraz załataj kryzys!” (nie wszyscy?)

Ma to wpływ na produktywność (i morale) personelu inżynieryjnego, w tym na własny rachunek. Kierownictwo poświęciło trochę czasu na zastanowienie się, jak zmniejszyć częstotliwość tych zamówień tego samego dnia i opracowało rozwiązanie, które będziemy wydawać co tydzień. (Wcześniej robiliśmy jeden raz na dwa tygodnie, co zwykle zmniejszało się o kilka dni.)

Jest 13 programistów i 6 lokalnych / 9 testerów offshore; zgodnie z teorią tylko 4 programistów (i wszyscy testerzy) będą pracować nad wydaniami o parzystych numerach, chyba że pojawi się praca, która naprawdę wymaga specjalistycznej wiedzy jednego z pozostałych deweloperów. Każdy cykl będzie zawierał dwa dni pracy deweloperów i dwa dni pracy zapewniania jakości (plus 1 dzień ustalania zakresu / triage / ...).

Moje pytania to:

(a) Czy ktoś ma doświadczenie w tym cyklu wydawniczym?

(b) Czy ktoś słyszał o takiej długości cyklu wydania?

(c) Jeśli (a) lub (b), jak, u licha, sprawiasz, że działa? (Wszelkie pułapki, których należy unikać itp., Są również mile widziane.)

(d) Jak możemy zminimalizować szkody, jeśli wysiłek się nie powiedzie?

Z pewnością możesz dostarczać co tydzień - a nawet częściej. W tej chwili zazwyczaj wydajemy co dwa tygodnie, ale nie jest niczym niezwykłym wdrażanie funkcjonalności, gdy coś dotarło bez powiadomienia od jednego z naszych partnerów, co byłoby nieistotne, gdybyśmy czekali na następny cykl. W pewnym momencie w ciągu najbliższych kilku miesięcy chciałbym, abyśmy przeszli na ciągłą dostawę (przedmioty są wypuszczane tak szybko, jak to możliwe po ich „ukończeniu”) w standardzie, ale nie jesteśmy jeszcze wystarczająco pewni, aby to zrobić daleko.

Najważniejsze jest to, aby Twoja witryna była silnie objęta automatycznymi testami - zarówno testami jednostkowymi, jak i kompleksowymi testami akceptacyjnymi / specyfikacjami wykonywalnymi. W konsekwencji oznacza to również, że twoja kompilacja jest w pełni zautomatyzowana. Na poziomie akceptacji używamy Robot Framework, który dzięki swojemu słowu kluczowemu doskonale nadaje się do szybkiego budowania łatwego do utrzymania pakietu testowego. Aby wyglądać i czuć, nasz tester na miejscu przeprowadza pobieżne kontrole, ale mamy również kilku facetów w Indiach, którzy dokładniej sprawdzają w różnych przeglądarkach (istnieją witryny, które pomagają w tego rodzaju sprawach, wykonując zrzuty ekranu dla Ciebie, np. BrowserLab ).

Nie w pełni automatyzujemy wdrożenie (ostatni krok wymaga ręcznej interwencji, jest to dla nas świadoma decyzja) - ale automatyzujemy wszystkie rzeczy, takie jak zapewnienie, że używane są prawidłowe połączenia z bazą danych itp., Z krótkimi cyklami wdrażania zbyt łatwo byłoby pomylić się z tego rodzaju rzeczami.

Jest całkiem niezła, najnowsza książka o ciągłej dostawie, którą możesz chcieć sprawdzić. Przejrzałem ją, ale jeszcze jej nie szczegółowo omawiałem. To, co do tej pory czytałem, dobrze współgra z naszymi doświadczeniami: Ciągłe dostarczanie: niezawodne wersje oprogramowania poprzez automatyzację kompilacji, testowania i wdrażania

Podsumowując, potrzebujesz wysoce zdyscyplinowanego zespołu, wysokiego poziomu automatyzacji i - co najważniejsze - niezwykle wysokiego stopnia zaufania do tej automatyzacji. Wydaje mi się, że przejście do tygodniowych cykli w twoim przypadku może być pomyłką - łatki kryzysowe wskazują na inne problemy i powinieneś pracować nad ich wyeliminowaniem. Zwiększenie tempa może potencjalnie pogorszyć sytuację ...

Jeśli ciągle jesteś w trybie „wydania kryzysowego”, powiedziałbym, że rozsądniej byłoby cofnąć się o krok i dokonać ponownej oceny kodu i procesu. Oczywiście istnieje pewna awaria, która wciąż się powtarza.

Chociaż może nie być to w pełni możliwe w prawdziwej skali produkcyjnej, prawdopodobnie warto byłoby mieć co najmniej jednego starszego członka oraz część innych programistów i testerów poświęconych tej ocenie.

„4 at at time” nie brzmi dla mnie jak wyraźny zwycięzca. Oznacza to stałe przełączanie kontekstu, co oznacza znacznie mniejszą wydajność.

Pamiętaj, że jeśli ciągle spieszycie się z wprowadzaniem zmian, istnieje większe prawdopodobieństwo popełnienia błędów w tych zmianach i zepsucia czegoś innego.

Cykle wydawania krótsze niż tydzień zostały z pewnością osiągnięte w branży oprogramowania. Stosują technikę zwaną ciągłą dostawą (zwaną także ciągłym wdrażaniem ).

Istnieje firma, która wydaje 50 razy dziennie. Ten post na blogu opisuje, jak to robią .

Zarząd poświęcił trochę czasu na zastanowienie się, jak zmniejszyć częstotliwość tych „kryzysowych prac” i opracował rozwiązanie, które będziemy publikować co tydzień.

Wygląda na to, że twój zarząd jest mistrzem świata ... dlaczego nie zainwestować w ducha zespołu? Zobaczysz, że problemy znikną same z siebie.

(a) + (b) IMHO, w zależności od wielkości twojego zespołu powinno to wynosić maksymalnie dwa tygodnie. Tydzień będzie działał dla koncertów jednego człowieka lub bardzo małych zespołów (np. 2 lub 3).

(c) + (d) Ale niezależnie od wielkości twojego zespołu lub projektu, jedną z pierwszych rzeczy, które robię, jest automatyzacja kompilacji i wdrożenia. Oszczędzam dni, jeśli nie tygodnie pracy, robiąc to na początku projektu.

Wdrożenia należy wykonać jednym kliknięciem. Od źródła do inscenizacji, a następnie od inscenizacji do produkcji. Jest wiele narzędzi, aby to umożliwić. Od ant / nant po superciężkie rzeczy, takie jak Automated Build Studio .

Wszystko można zautomatyzować, od wdrożeń plików do aktualizacji bazy danych, w tym kopii zapasowych, powiadomień, raportów ...