Zaczynając pracę w IT jedną z pierwszych rzeczy, jaka rzuci się Wam w oczy i uszy, będzie obecność wielu angielskich zwrotów oznaczających różne tajemniczo brzmiące pojęcia. Podobnie jest z naszym dzisiejszym bohaterem- deploymentem.

Czym jest deployment? Jest pojęciem, które przed adaptacją do branży IT było przede wszystkim kojarzone z armią. Oznacza „przeniesienie wojsk lub sprzętu na miejsce/pozycję akcji militarnych”. Jest mocno skorelowane z zastosowaniem danej rzeczy na określonym terenie.

Nie inaczej jest ono stosowane w IT. Według wielu definicji, które możemy znaleźć chociażby na angielskiej wikipedii określenie to odnosi się do „ogółu czynności i procedur, jakie trzeba wykonać, aby aplikacja była gotowa do użycia”. Co jednak bardzo istotne- deployujemy zawsze dokądś. Na określony serwer, do określonego środowiska. Pod tym względem pojęcie to bardzo zbliżone jest do jego pierwotnego wojskowego zastosowania.

Do czynności wykonywanych w czasie deployementu może zaliczać się szereg akcji, które często są od siebie zależne:

• instalacja oprogramowania
• konfiguracja
• uruchomienie (ang. running)
• testowanie
• dokonanie koniecznych poprawek wykrytych w czasie testów

Potocznie pomiędzy programistami pojęcie „zdeployować” można rozumieć jako „wgrać w określone miejsce i uruchomić”. W niektórych źródłach znajdziemy również, że deployement jest nastepstwem ukończonego procesu developmentu. Jestem skłonna zgodzić się z tym stwierdzeniem pod warunkiem, że ów development będziemy traktować jako dowolnie małą jednostkę. Zdeployowanie kolejnej wersji nie wymaga bowiem ukończenia developmentu całego projektu.

Warto pamiętać, że deployment jest pojęciem bardzo ogólnym i sam w sobie nie determinuje akcji, jakie muszą zostać w jego ramach wykonane. Szereg koniecznych czynności w dużej mierze zależy od środowiska, na które deployujemy oraz od tego, co deployujemy.

Środowiska

W poprzednim akapicie wspominałam o środowiskach jako miejscach, na których wykonujemy deploymenty. Chciałabym, abyście myśleli o nich właśnie jako o fizycznych miejscach. Niejednokrotnie chcemy, aby nasza aplikacja działała w różnych obszarach w zależności od przeznaczenia.

Przykładowo stabilną wersję aplikacji, którą udostępniamy użytkownikom końcowym, nazywamy wersją produkcyjną. Użytkownikami końcowymi są osoby, które bezpośrednio korzystają z aplikacji zgodnie z jej przeznaczeniem. Jeśli korzystasz z aplikacji bankowej w Twoim telefonie, jesteś jej użytkownikiem końcowym. Podobnie rzecz ma się w odniesieniu do aplikacji webowych. Wersja produkcyjna aplikacji umieszczana jest w trakcie deployementu na środowisku produkcyjnym, potocznie „na produkcji”. Jest to wersja, na którą wszyscy są bardzo wyczuleni, a każdy błąd programistów, może słono kosztować klienta, gdyż utrudnia życie realnym użytkownikom. Samo „wejście na produkcję” jest już nie lada wyczynem, ponieważ oznacza, że projekt musiał już przebyć długą drogę do momentu, gdy aplikacja jest gotowa na pokazanie jej światu. Czy świętowaliście już kiedyś wejście na produkcję? Poszliście kiedyś live? 😉

Całkowicie innym środowiskiem jest środowisko deweloperskie. Jest to działająca kopia kodu, do której programiści nieustannie dołączają nowe funkcjonlaności, a całość testowana jest pod względem integracji poszczególnych części kodu w jedną calość. Środowisko te jest dynamicznie i często aktualizowane. Zawiera najświeższą wersję aplikacji. Tutaj programiści nie obawiają się tak bardzo deployowania kolejnych wersji.

Przedstawiłam Wam dwie skrajności- środowiska produkcyjne i deweloperskie stanowią dwa przeciwległe końce wachlarza środowisk stosowanych w IT. Pomiędzy nimi w zależności od aplikacji, potrzeb i projektu mogą stać następujące środowiska:

• Staging environment, tak zwany stage, czyli środowisko poświęcone większym „wydaniom” (wersjom) aplikacji, które następnie mają wejść na produkcję. Zazwyczaj stage jest odbiciem 1:1 środowiska produkcyjnego, Głównym celem jest sprawdzenie i przetestowanie wszystkiego ZANIM wejdziemy na produkcję. To na nim również zaangażowani w projekt interesariusze i managerowie po stronie klienta będą oglądali aplikację i na tej podstawie ją akceptowali. Zazwyczaj stage jest też ostatnim krokiem przed wejściem na produkcję. Oznacza to, że zawiera wersję aplikacji n+1, podczas, gdy na produkcji mamy wersję n.
• Quality assurence environment, rzadziej spotykane, ale służace testerom do testowania bardziej stabilnej, nie tak często jak na środowisku deweloperskim zmieniającej się wersji aplikacji.

Czym jest release?

Być może spotkaliście się już z podobnym stwierdzeniem: „W tym tygodniu nie mogę. W czwartek mamy release aplikacji. Jest starsznie dużo pracy i wszyscy są przejęci i zestresowani„. Release to nic innego jak wydanie kolejnej wersji aplikacji. Niejednokrotnie okupiony jest ciężką pracą całego zespołu deweloperskiego. Nie dość, że w skład release’a wchodzą określone funkcjonalności, które należy dostarczyć, to jeszcze niejednokrotnie związane jest to z przygotowywaniem całej otoczki wydania: dokumentacji, skryptów migracyjnych dla bazy, manuali itd. Dodajmy do tego testerów, którzy znacząco przyczyniają się do podnoszenia jakości wersji aplikacji zgłaszając developerom wykryte błędy (ang. bugi), a otrzymacie wybuchową, przedreleasową mieszankę.

Nie należy jednak się poddawać, zgodnie z mottem, iż:

---

” Do ostatniego dnia przed releasem liczy się liczba dostarczonych funkcjonalności. Od pierwszego dnia po releasie już tylko liczba zgłoszonych usterek. „

---