Przejdź do treści

O release’ach myśli nieuczesane

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.

1 komentarz do “O release’ach myśli nieuczesane”

  1. Ważne jest wzięcie pod uwagę specyfiki „biznesu” w którym się poruszamy. W dzisiejszym IT jest zdecydowanie więcej dynamizmu niż kiedyś i ten dynamizm często z góry przekreśla wielkie „releasy”, bo zmiany muszą pojawiać się w sposób ciągły. I nie dotyczy to tylko małych, eksperymentalnych serwisów. Facebook na przykład ma release co tydzień mimo, że koszta wprowadzenia ewentualnego błędu byłyby olbrzymie (pewnie sporo większe niż w niejednym banku;).

    Można więc się zgodzić z końcowym stwierdzeniem „it depends”. Można też doszczegółowić, że jeśli poruszamy się we w miarę statycznym środowisku klasy enterprise, gdzie jest jasno określony klient, użytkownik, odbiorca … to być może duże releasy będą tym czego wszyscy tak na prawdę chcą. Jeśli robimy produkt pudełkowy, który sprzedajemy co jakiś czas komu się da – to w ogóle nie ma dyskusji i robimy releasy (windows 8 nadchodzi;). Ale jeśli działamy w nieco szerszym, dynamicznym środowisku (wielu luźno związanych klientów lub szeroka grupa użytkowników o których względy musimy nieustannie zabiegać), lub gdy bardziej sprzedajemy „service” niż „software” to prawdopodobnie lepiej nam będzie z jakimś lżejszym narzędziem wspartym masową automatyzacją testów, budowania i instalowania.

    Taką lekką wersją może być kompletne przeciwieństwo dużych releasów. To znaczy wdrażanie zmian pojedynczo, małym kroczkami, bardzo często. Nie musi to wcale oznaczać chaosu i niskiej jakości. Jeśli tylko wyeliminujemy z naszego procesu większość nudnych manualnych czynności i dobrze obmyślimy kwestię zautomatyzowania testów, to podejście takie może wręcz podnieść nam finalną jakość. Choć zdecydowanie nie jest to za darmo ani automatycznie.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.