Wydawanie oprogramowania w cyklu
2011-05-30
Już kilka razy zdarzało mi się tłumaczyć znajomym, jak organizujemy prace programistyczne w Fablo . Ponieważ wygląda na to, że informacje te mogą być przydatne dla wielu osób, zamierzam napisać serię artykułów na ten temat. Na początek o cyklach wydawania oprogramowania.
W Fablo staram się wymusić regularny cykl wydań. Nasze oprogramowanie pojawia się w formie wydań (z numerem wersji) raz na tydzień, z okazjonalnym wydłużeniem cyklu do dwóch tygodni w przypadku większych prac. Pojedynczy cykl wygląda tak:
- w każdy czwartek przygotowujemy wydanie oprogramowania,
- w czwartek lub piątek trafia ono na instalację testowo-demonstracyjną,
- wprowadzane są poprawki,
- w środę kolejnego tygodnia w przypadku braku problemów oprogramowanie przenoszone jest na serwery produkcyjne.
Dlaczego wydajemy tak często? Powodów jest kilka:
Dyscyplina programowania. Trudniej jest polerować bez końca jeden fragment kodu, gdy wiadomo, że musi pojawić się w działającej wersji w ciągu kilku dni. Cotygodniowe wydania powodują, że trzeba się skupiać na dostarczaniu używalnego kodu.
Szybsza droga zmian do klienta. Po wprowadzeniu zmian, o jakie prosili klienci, czas oczekiwania aż pojawią się w wersji produkcyjnej to maksymalnie 2-3 tygodnie.
Umiejętność robienia wydań. Gdy wydaje się rzadko, każde wydanie staje się Problemem. Im rzadziej się to robi, tym trudniej jest się zebrać do wydania i łatwiej o pomyłki i przeoczenia.
Testowanie. Wbrew pozorom nie jest dobrze, gdy testy „gałęzi stabilnej” trwają zbyt długo. Powoduje to, że programiści przestają używać kodu „stabilnego” na swoich komputerach. Eliminujemy w ten sposób największą grupę testerów i często okazuje się, że „stabilnego” kodu nie testuje faktycznie nikt. Dlatego lepiej, by kod „stabilny” różnił się jak najmniej od tego, który rozwijają programiści.
Zdefiniowany kierunek. Każde wydanie ma swoją wiodącą funkcjonalność, widoczną dla użytkownika. Wiadomo dzięki temu jaki jest kierunek zmian i czemu podporządkowane są prace.
Szybka informacja zwrotna. Gdy oprogramowanie trafia do klientów z opóźnieniem dwóch tygodni, można szybko wykorzystać informację zwrotną do zmian kierunku. Przy dłuższym cyklu pojawia się spora szansa, że robilibyśmy miesiącami coś, co nie jest klientom potrzebne.
Oczywiście częste wydawanie ma też swoje wady. Najistotniejsze to:
Niektóre zmiany nie mieszczą się w tak krótkim cyklu. Zaimplementowanie większej funkcjonalności potrafi zająć dłużej niż tydzień lub nawet dwa.
Narzuty wprowadzone przez samo wydawanie oprogramowania są znaczące.
Jeśli chodzi o pierwszą wadę, to staram się większą funkcjonalność rozbijać na mniejsze zadania, dostarczalne i testowalne w krótszych okresach czasu. Moim zdaniem wychodzi to oprogramowaniu i pracom na dobre.
Na drugą z wymienionych wad nie mam odpowiedzi. Tak po prostu jest i jedyne co można zrobić to starać się automatyzować czynności związane z wydawaniem tak, by te narzuty minimalizować.
Uważam, że krótki cykl wydawania oprogramowania jest zdrowy i stanowi świetne narzędzie, szczególnie w młodej i szybko rozwijającej się firmie.
Ad. Narzuty wprowadzone przez samo wydawanie oprogramowania są znaczące.
Wydaje mi się, że de facto ten narzut i tak by trzeba było zapłacić, tylko kiedy indziej.
Tzn robiąc deploy raz na pół roku, trzeba poświęcić np 2 tygodnie na ustabilnienie, podczas, gdy co tydzień wystarczy np 2 godziny.
Wydaje mi się, że powstaje też oprogramowanie wyższej jakości, ponieważ, kultura ciągłego łatania bugów i korzystania z feedbacku w praktyce oznacza, że jest mniej błędów czy mało użytecznych fragmentów aplikacji.
Robienie deploy'u raz na dwa tygonie to nie szczyt możliwości, w wybranych projektach (w zależności od wielkości), zdarza nam się robić deploy'e 2x w tygodniu (duży projekt, duże pokrycie testami automatycznymi, również ręczne testowanie regresji), po każdym feature'że na server testowy i dalej (mniejsze projekty dobrze obtestowane, bez ręczneych testów regresji), codziennie przed 12 prosto na produkcje (małe projekty - np 1 os, klient testuje na bierząco)
Marek: zgadzam się, że oprogramowanie jest wyższej jakości — dokładnie to obserwuję. Co do narzutów to jednak uważam, że są większe gdy wydaje się częściej. Mimo wszystko: nawet powtarzalnych czynności trzeba wykonać więcej.
Wydania dwa razy na tydzień to bardzo często. Nie wyobrażam sobie takiej częstości w małym zespole i przy oprogramowaniu, które ma użytkowników (dochodzi kwestia pisania release notes, informacji dla użytkowników, tłumaczenia zmian, itp). U nas na pewno nie dalibyśmy rady, nawet raz na tydzień jest ciężko. Jestem pod wrażeniem, że udaje się Wam robić wydania tak często.
A jak Clojure? Sprawdza się w codziennym użyciu i rozwoju oprogramowania?
Tomek: rewelacyjnie. Sądzę, że trudno by było osiągnąć to co zbudowaliśmy bez Clojure. A konkretniej — trudno by było mieć tak zwarte i niezawodne oprogramowanie o tak dużej funkcjonalności, w tak krótkim czasie, bo wiadomo że ogólnie to można napisać wszystko we wszystkim.
dobry tekst. trackbackuje http://kubafilipowski.com/continuous-deployment
Hej,
jakie sa te powtarzalne czynności?
U nas to jeden przycisk + 3 min gapienia się w ekran ;)
Wiktor: wszystko zależy od tego o jakim oprogramowaniu mówimy. U nas zdarzają się rzeczy, które się _pisze_ 2 tygodnie. A co do czynności — uaktualnienie dokumentacji klienta, wstawienie release notes do gazetki, opisanie zmian w sposób krótki i łatwo zrozumiały dla klientów, praca z klientami nad ewentualną migracją ustawień lub konfiguracji — jest tego sporo. Nawet nie wspominam już o samym upgrade naszych instalacji w Amazon AWS.
Pamiętajmy, że w Fablo mamy stronę serwerową (Clojure) i kliencką (Javascript), i niekoniecznie zawsze możemy uaktualnić wszystko równocześnie.
Moim zdaniem dojrzałego oprogramowania nie można wydawać codziennie.
Ad Wszystko zależy od tego o jakim oprogramowaniu mówimy. U nas zdarzają się rzeczy, które się _pisze_ 2 tygodnie
I tak i nie :) Zawsze robimy deploy tego co gotowe, co nie gotowe, tego nie deployujemy (trzymamy w branchach) :)
Więc jeśli są same duże feature'y w trakcie to albo nic nie deploy'ujemy, albo np tylko małe bugfixy.
Jak tylko jednak feature jest gotowy to posyłamy go na produkcje w najbliższym deploy'u.
Robienie deploy'ów np 2x w tygodniu ma sens dla większych projektów, gdzie jest dodatkowy narzut związany
z deployem np ręczne testowanie regresji. W mniejszych projektach deploy idzie po każdym zrobionym tickecie.
Ad. Moim zdaniem dojrzałego oprogramowania nie można wydawać codziennie
Może nie tyle nie można (patrz wordpress, kilkadziesiąt deploy'ów dziennie), co często nie ma sensu.
Marek:
> Ad. Moim zdaniem dojrzałego oprogramowania nie można wydawać codziennie
> Może nie tyle nie można (patrz wordpress, kilkadziesiąt deploy'ów dziennie) [...]
Nie uważam wordpressa za dojrzałe oprogramowanie :-)