Rozwijasz jakieś oprogramowanie. Wykonujesz w nim zmiany. Te zmiany od czasu do czasu musisz pokazać światu – czyli musisz dostarczyć swój system użytkownikom lub umieścić go na serwerze. I tutaj pojawia się słynne pytanie Hamleta: „to release or not to release”.

Zacznijmy od małej dygresji lingwistycznej: nie ma dobrego tłumaczenia terminu „release” na język polski. Spotkałem się z tłumaczeniem na słowo „wydanie” – ale jest to tłumaczenie dla mnie dość sztuczne. Wśród deweloperów pojedynczy release określa się często słowem „paczka” – ale ono też nie oddaje dobrze istoty sprawy. Dlatego w artykule będę posługiwał się słowem angielskim. Dodatkowo mamy też wieloznaczność polegającą na tym, że słowo „release” może oznaczać zarówno cały model wytwarzania oprogramowania, jak też i pojedyncze wydanie kolejnej wersji systemu…

I mając już za sobą skomplikowane kwestie lingwistyczne, możemy już przejść do istoty sprawy.

Cóż to jest ten release?

Zacznijmy od próby zdefiniowania pojęcia: kiedy mamy do czynienia z release’ami?

Idea świata release’ów jest bardzo prosta – mając zestaw zmian w systemie, grupujemy je w zbiory, po to aby przetestować je razem i jednym ruchem wdrożyć na środowisko produkcyjne. W świecie idealnych release’ów mamy ustalony z wyprzedzeniem plan wydawania kolejnych wersji naszego produktu, a każda z tworzonych zmian jest przypisywana do jednego z release’ów.

W wielu środowiskach pracy taki model pracy jest czymś oczywistym i naturalnym – na przykład zespoły Scrumowe powinny tworzyć release systemu po każdej z iteracji. Ale nie jest to jedyny możliwy model rozwoju oprogramowania. Alternatywą jest model, w którym każda zmiana jest wdrażana na środowisko produkcyjne niezależnie od innych. Jednocześnie pracujemy nad wieloma zmianami w systemie, w momencie kiedy któraś z nich jest skończona i przetestowana – tworzymy nową wersję naszej aplikacji i przekazujemy ją na środowisko produkcyjne.

Jeżeli pracujemy w środowisku, w którym release’y są i działają sprawnie – pozostaje tylko się z tego cieszyć. Jeżeli pracujemy w środowisku, w którym release’ów nie ma, ale jakoś ten brak nam nie doskwiera – to najrozsądniejszą rzeczą wydaje się utrzymanie tego stanu rzeczy. Cała zabawa zaczyna się w momencie, kiedy nie mamy release’ów, a chcemy je wprowadzić. Są środowiska pracy, gdzie można wykonać to dość małym kosztem – i jeżeli pracujesz w takim środowisku, to może zdziwi cię wiadomość, że są również takie środowiska, w których wprowadzenie modelu release’ów wiąże się z niemałym wysiłkiem i często bywa długotrwałym projektem…

Gdzie jest problem?

A zatem: cóż trudnego może być we wprowadzeniu release’ów?

Po pierwsze: release trzeba gdzieś przetestować. Musisz mieć serwer testowy, na którym możesz uruchomić swój program czy serwis – a w większości przypadków będziesz potrzebował więcej niż jednego środowiska testowego. W praktyce często jedno środowisko służy do testów bieżącego release’u , podczas gdy drugie środowisko odzwierciedla bieżące środowisko produkcyjne i służy do testowania ewentualnych quick fix’ów. Jeżeli możesz uruchomić swój program na dowolnym pececie, na którym jest zainstalowany Apache oraz baza MySQL – to zasadniczo problemu nie ma, stworzenie i uruchomienie takiego środowiska testowego jest sprawą tanią i prostą. Gorzej natomiast, jeżeli Twój system potrzebuje do uruchomienia serwera z 10 procesorami SPARC oraz bazy danych pracującej wyłącznie pod kontrolą systemu AIX – wtedy koszty stworzenia i utrzymania środowiska testowego nie są już banalne i kwestia ilości takich środowisk ma już duże przełożenie na koszty.

Po drugie: niezależnie od tego, jakie oprogramowanie dostarczasz, to jest ono zawsze wykonywane dla potrzeb jakiegoś klienta – a klient zawsze czeka na zmiany. Wdrożenie release’ów zawsze oznacza wydłużenie czasu dostarczenia zmiany na produkcję, określaną jako Time-To-Market. Mamy jakąś zmianę, której stworzenie i przetestowanie zabrało jeden dzień – ale jeżeli nie jest to zmiana krytyczna, to zostanie ona wdrożona dopiero za jakiś czas wraz z najbliższym release’em. Czy możemy sobie na to pozwolić? W wielu przypadkach tak. Ale są też produkty, dla których minimalizacja czasu wprowadzenia niektórych zmian stanowi „być albo nie być” dla tego produktu lub usługi.

Po trzecie: jeżeli zmiany w twoim systemie są wspólnie zarządzane, to jesteś w dobrej sytuacji. Gorzej jest, jeżeli na twój system ma wpływ szereg projektów, z których każdy jest w innej fazie i ma inny termin planowanego wdrożenia na produkcję. Jeszcze gorzej jest, jeżeli terminy tych wdrożeń na produkcję są trudne do przesunięcia…

Po czwarte: jeżeli pracujesz nad zmianami w tylko jednym systemie, to jesteś w dobrej sytuacji. Gorzej jest, jeżeli w Twoim środowisku pracy toczą się równoległe prace w różnych systemach i pewne zmiany w różnych systemach muszą być wprowadzone razem bądź w ściśle określonej kolejności. Wówczas albo musisz mieć wspólne release’y dla wszystkich systemów – albo nie będziesz mieć ich wcale.

Ale to jeszcze nie wszystko…

Co jeszcze będzie ci potrzebne do wprowadzenia release’ów? Oczywiście system kontroli wersji i użytkownicy, którzy potrafią świadomie z tego systemu korzystać. Często bywa tak, że pracując nad kolejnym release’m trzeba wprowadzić zmiany do poprzedniego. Przydadzą się wtedy gałęzie, tagi, merge’owanie oraz osoby które potrafią je obsługiwać.

Będziesz też potrzebował narzędzia, które będzie prezentowało listę zmian, które są wprowadzane do kolejnych release’ów. Może być to osobne narzędzie typu „Release Portal”, może być to część większego systemu wspierającego rozwój systemu. A z im większą liczbą innych narzędzi (system kontroli wersji, bug tracker, system zarządzania projektem…) zintegrujesz to ustrojstwo – tym lepiej.

Jeżeli na Twój system ma wpływ wiele projektów, to zdecydowanie potrzebujesz przydzielenia jakiejś osobie roli „release mastera” – czyli osoby odpowiedzialnej za koordynację tworzenia release’ów oraz komunikację z projektami. Z pewnością za jakiś czas zdarzy się tak, że projekt A będzie chciał wdrożenia w lutym, a projekt B w połowie marca, projekt C będzie chciał wydłużenia release’u o dwa tygodnie żeby poprawić błędy, natomiast projekt D oprotestuje takie wydłużenie. Ważne jest to, aby „Release Master” był rzeczywiście partnerem, który może wpływać na decyzje projektowe – w przeciwnym razie plan release’ów będzie miotany przez projekty na prawo i lewo.

Procedura tworzenia pojedynczego release’u musi być jasna dla wszystkich – a jeżeli uczestniczy w niej więcej niż jeden zespół, to dobrze jest ją spisać.

I musisz też mieć – o ile jeszcze nie masz – automatyzację wdrażania zmian na środowisko produkcyjne. I znowu, w niektórych systemach jest to proste i naturalne, ale są też systemy, w których wdrażanie zmian jest procesem żmudnym i długotrwałym.

A w zasadzie, to po co ta cała zabawa?

Policzmy: musimy mieć środowiska testowe, konieczność synchronizacji między projektami, spisaną procedurę i konieczność stosowania się do niej, automatykę wdrażania release’u, kontrolę wersji z różnymi gałęziami kodu, a w nagrodę otrzymujemy dłuższy czas wdrożenia zmian. Po co więc to wszystko? Powód jest bardzo prosty. Jeżeli przed wdrożeniem zmian konieczne jest przeprowadzenie dokładnych testów systemu – możemy przeprowadzić te testy jednocześnie dla wielu zmian. Zmniejszamy tym samym koszt testu dla pojedynczej zmiany. Minimalizujemy też ryzyko konfliktu lub niepożądanych zależności między różnymi zmianami rozwijanymi w tym samym czasie.

Ale są też firmy, które świadomie rezygnują z release’ów, aby uprościć procedury i skrócić Time-To-Market. Zamiast tego dokładają starań, aby zmiany, nad którymi równolegle pracują, były jak najmniej zależne od siebie. Tak też można.

To w sumie dłuższej czy krócej?

I to już miał być koniec artykułu, gdyby nie to, że przeczytał go Witold, podkreślił w powyższych akapitach wyrażenia ze słowami „dłużej” i „krócej” – i stwierdził, że nie zawsze tak musi być. I ma rację. Jeżeli mamy 4 projekty (A, B, C i D) rozwijane równolegle i przy rozwoju bez stosowania release’ów – to z punktu widzenia każdego z tych projektów wdrożenie powinno być szybsze niż w wersji z release’ami. Zmiana C jest gotowa – wrzucamy ją na produkcję i już. Ale czy wdrożenie wszystkich projektów (A, B, C, D) będzie szybsze bez zastosowania release’ów, to już zupełnie inne pytanie. Może być tak, że wdrożymy na produkcję projekty B i C – i w tym momencie okazuje się, że musimy też znacząco zmienić rozwijany projekt A, co zajmuje czas. Czyli kwestia „dłużej czy krócej” zależy to przede wszystkim od ilości zmian w systemie i od stopnia zależności pomiędzy tymi projektami.

Toczymy tutaj pewną grę z ryzykiem. Nie stosując release’ów ryzykujemy, że wdrożenie pewnej zmiany opóźni nam wdrożenie kolejnych zmian. Stosując je – ryzykujemy, że jeżeli w zbiorze zmian jest jedna opóźniona, to wtedy opóźnia się wdrożenie całości.

Tak więc na pytanie „to release or not to release” nie ma jednoznacznej odpowiedzi. Stosowanie release’ów przynosi sporo korzyści – ale często też koszt ich wprowadzenia jest bardzo duży. To, czy jest to koszt opłacalny, zależy od wymagań dotyczących naszego systemu, ilości zmian w tym systemie, stopnia zależności między tymi zmianami. Tak więc… it depends, Mr Hamlet, it depends.