Release, deployment, wdrożenie itd. Pojęcia nadzwyczaj często używane zamiennie. Zdarza się, że nawet w ramach jednego zespołu. Problem lingwistyczny czy techniczny? A może nawet świadome proszenie się o poważne kłopoty przy produkcji? Zacznij je rozróżniać, a zaoszczędzisz sporo pieniędzy i problemów. 🙂

Ujednolicenie definicji

Na wstępie zastanówmy się, czy istnieją w powyższym obszarze całkowicie spójne definicje. W przypadku słowa „deployment”, czyli po prostu „wdrożenie”, jest to w miarę jasne. Rozumiemy przez nie instalację oprogramowania w wybranym środowisku. Ze słowem „release” nie jest już tak różowo. Przetłumaczmy to jako „wydanie”. Pierwsze pytanie, na które musimy odpowiedzieć, to czy rozmawiamy o czasowniku czy rzeczowniku. Na pierwszy rzut oka różnica niewielka, ale czy na pewno? Wydanie jako rzeczownik oznacza określoną wersję oprogramowania. Na przykład Fedora Linux 28. Liczba jest tutaj właśnie kolejnym numerem wydania. W języku angielskim powiemy „release 28”. A czasownik? Przez wydanie oprogramowania (ang. to release) rozumiemy jego upublicznienie. Udostępnienie nowych funkcji użytkownikom. W przypadku szeroko wykorzystywanych systemów web, to właśnie wydawanie i wdrażanie są bardzo często traktowane jako tożsame.

O co tyle zachodu – to tylko słowa?

Na pewno? 🙂 Wracając do postawionego we wstępie pytania: czy to problem lingwistyczny, czy techniczny? A może oba jednocześnie? Ignorowanie różnicy między tymi wyrażeniami wynika głównie z ograniczeń technologicznych i procesowych. Zastanówmy się więc, jakie są konsekwencje ujednolicenia tych dwóch pojęć. Jednoczesne wdrożenie i upublicznienie nowych funkcji (bądź ich nowych wersji) pociąga za sobą kilka niebezpieczeństw.

Wyobraźmy sobie sytuację, kiedy wypuszczamy na rynek nowy produkt – niech będzie to nowa oferta internetu mobilnego. Jej sprzedaż wymaga użycia nowej wersji oprogramowania. Oczywiście wszystko przetestowaliśmy na środowiskach test, staging, UAT etc. Oferta startuje 10 grudnia. Akurat dwa tygodnie szalonych zakupów przed świętami. Reklamy w telewizji i radiu ustawione. W nocy z 9 na 10 grudnia robimy wdrożenie. O 5:00 rano kończymy i szybko okazuje się, że coś jest nie tak. Nie wyświetla się lista urządzeń. Bardzo, bardzo niedobrze. Punktualnie o 9:00 salony zaczną szturmować pierwsi klienci, a my jesteśmy w lesie. Ostatecznie problem udaje nam się rozwiązać o godzinie 11:00. Zarząd wściekły, marketing raczej myślał o innej formie reklamy i nie do końca dają się przekonać słynnym twierdzeniem, że „nie ważne, co się mówi, ważne, że się mówi”.

Teraz druga sytuacja. Mniej dramatyczna. System backoffice wykorzystywany w firmie X. Biznes od dawna czeka na możliwość przepinania klientów między agentami. Właśnie z dzisiejszym wdrożeniem weszła na produkcję. Wszyscy są zachwyceni i od razu przystępują do działania. Nagle okazuje się, że przy okazji wdrożyliśmy też poważny błąd w mechanizmie fakturowania. Co robimy? Wycofujemy wersję, ryzykując lincz ze strony zachwyconych sprzedawców? Czy stawiamy na szali nasze dobre relacje z działem księgowym?

Co tak naprawdę miało miejsce? Zrobiliśmy wdrożenie i upublicznienie zmian jednocześnie. W ramach tej samej czynności. Dlatego, że nie odróżniliśmy jednego od drugiego. To problem, który, jak widać, może pociągać za sobą bardzo poważne konsekwencje. Warto przestać go ignorować.

Wdrażanie bez wydawania

Czy można wdrożyć bez upubliczniania zmian? Jak się łatwo domyśleć, gdyby było inaczej, nie powstałby ten artykuł. 🙂 Najprostszą metodą jest zastosowanie wspomnianych w poście o ciągłej integracji przełączników (feature flags). Taki przełącznik może przybierać bardzo różne formy. W najprostszej wersji może to być uprawnienie do danego typu transakcji. Wdrażamy oprogramowanie wspierające nową ofertę internetu mobilnego. Ale poza kilkoma wybranymi użytkownikami nikomu nie dajemy do niej dostępu. To jest czas, w którym możemy zweryfikować działanie wszystkiego na produkcji. Gdy pojawią się błędy, zdążymy je spokojnie naprawić. W godzinie zero wystarczy nadać odpowiednie uprawnienia pracownikom i tym samym udostępnić im wdrożone wcześniej funkcje. Gratulacje. Właśnie rozdzieliliśmy deployment i release. Innym rodzajem przełącznika jest standardowa „feature flag”. Wyrażenie IF, które pozwala wybrać między starą a nową gałęzią kodu. Sterowana może być wartością kolumny w bazie danych, datą, zmienną środowiskową etc. Paleta możliwości jest bardzo szeroka.

Ciągłe wdrożenia czy ciągłe wydania?

Wdrożenie to wydarzenie techniczne. Wydanie to wydarzenie sprzedażowo-marketingowe (bądź, jak mawiają moi wspólnicy, smarketingowe). Poza zainstalowaniem wersji, musimy zatem zadbać o kilka nietechnicznych rzeczy. Zaktualizować dokumentację użytkownika, wysłać komunikację do klientów, opublikować posta na Facebooku, zorganizować webinar, przeszkolić operatorów systemu etc. Jest to kolejny powód, dla którego ignorowanie różnicy między obydwoma wydarzeniami nie zaskarbi nam przychylności biznesu. Obecnie dość dużo wysiłku wkłada się w migrację do modelu „continuous deployment”. Nazwa nie bez powodu jednak zawiera słowo „deployment”, a nie „release”. Nie chodzi o to, aby codziennie zmuszać biznes do wykonywania wszystkich wspomnianych powyżej czynności, tylko o wdrażanie zmian na tyle często, aby nie kazać klientowi czekać, jeżeli zdecyduje się z nich skorzystać.

Jak widać, między tymi dwoma magicznymi słowami jest znacznie większa różnica niż tylko w warstwie językowej. Uważam, że zdecydowanie warto zdawać sobie z niej sprawę! A Ty? 🙂

1
Dodaj komentarz

avatar
1 Comment threads
0 Thread replies
0 Followers
 
Most reacted comment
Hottest comment thread
1 Comment authors
Sebastian Recent comment authors
  Subscribe  
najnowszy najstarszy oceniany
Powiadom o
Sebastian
Gość
Sebastian

Bardzo ciekawe. W rzeczywistości nigdy tak na to nie patrzyłem. Dzięki.