Deploy a release – różnice i jak je rozdzielić w praktyce

Deploy (wdrożenie) to techniczna operacja: nowa wersja kodu trafia na serwery, do kontenerów albo do sklepu z aplikacjami. Release (wydanie) to decyzja biznesowa: użytkownicy zaczynają z tej zmiany korzystać. W małych projektach obie rzeczy dzieją się jednocześnie, więc łatwo je mylić, ale w dojrzałych zespołach celowo się je rozdziela.

Rozdzielenie deployu od release’u pozwala wdrażać kod wiele razy dziennie przy niskim ryzyku, a nowe funkcje włączać wtedy, gdy jest na nie gotowy marketing, wsparcie i infrastruktura. Poniżej wyjaśniam oba pojęcia, drugie znaczenie słowa „release” i techniki, które pozwalają oddzielić jedno od drugiego.

Co to jest deploy (wdrożenie)

Deploy to proces umieszczenia zbudowanego artefaktu (paczki, obrazu kontenera, binarki) w konkretnym środowisku i uruchomienia go tam. Środowiskiem może być testowy staging, ale w rozmowie o „deployu” najczęściej chodzi o produkcję.

Typowe przykłady wdrożenia:

• podmiana obrazu kontenera w klastrze Kubernetes (kubectl set image, helm upgrade, synchronizacja w Argo CD),
• rozesłanie nowej wersji aplikacji na serwery playbookiem Ansible,
• skopiowanie plików i restart usługi przez systemctl restart,
• opublikowanie nowej wersji funkcji w chmurze (AWS Lambda, Azure Functions).

Deploy to wydarzenie techniczne, za które odpowiada zespół inżynierski. Sukces mierzy się tym, czy nowa wersja działa, przechodzi health checki i nie generuje błędów. Użytkownik nie musi go w ogóle zauważyć.

# Przykład: wdrożenie nowej wersji obrazu w Kubernetes i obserwacja rolloutu
kubectl set image deployment/sklep-web web=registry.example.com/sklep-web:2.4.0
kubectl rollout status deployment/sklep-web

Co to jest release (wydanie)

Release w sensie produktowym to moment, w którym zmiana staje się dostępna dla użytkowników: pojawia się nowy przycisk, zmienia się cennik, działa nowy endpoint API. To decyzja, którą często podejmuje product owner, a nie inżynier, i którą można rozłożyć w czasie, np. najpierw 1% użytkowników, potem 10%, potem wszyscy.

Wydanie można też cofnąć bez cofania kodu. Jeśli nowa funkcja jest schowana za flagą, wyłączenie jej trwa sekundy, podczas gdy rollback wdrożenia wymaga przebudowania lub przełączenia całej wersji aplikacji.

Drugie znaczenie: release jako wersja artefaktu

W codziennej pracy słowo „release” pada też w zupełnie innym kontekście — jako oznaczona, niezmienna wersja oprogramowania:

• Release w Git i na GitHubie/GitLabie to tag (np. v2.4.0) z opisem zmian i dołączonymi plikami binarnymi.
• Release w Helmie to zainstalowana w klastrze instancja wykresu, np. helm install sklep ./chart tworzy release o nazwie sklep, a każde helm upgrade dodaje jego kolejną rewizję.
• Release candidate (RC) to wersja kandydująca do wydania, testowana przed oznaczeniem jako stabilna.

# Oznaczenie wersji i utworzenie release'u na GitHubie (GitHub CLI)
git tag -a v2.4.0 -m "Wersja 2.4.0"
git push origin v2.4.0
gh release create v2.4.0 --generate-notes

W tym znaczeniu kolejność jest odwrotna: najpierw tworzysz release (wersję), a potem ją wdrażasz na kolejne środowiska. Gdy więc ktoś w zespole mówi „wypuszczamy release 2.4”, warto dopytać, czy chodzi o zbudowanie wersji, wdrożenie jej, czy włączenie funkcji klientom. Jeśli rozróżnienie Git i platform hostingowych jest dla Ciebie nowe, zajrzyj do tekstu Git a GitHub — czym się różnią.

Deploy vs release – porównanie

Dlaczego warto rozdzielić deploy od release’u

Kiedy deploy oznacza automatycznie release, każde wdrożenie jest jednocześnie premierą. Zespół zaczyna więc wdrażać rzadziej i w większych paczkach, a im większa paczka, tym trudniej znaleźć przyczynę błędu i tym boleśniejszy rollback.

Po rozdzieleniu:

1. Kod trafia na produkcję małymi porcjami, często, a niedokończone funkcje są w nim wyłączone.
2. Nowa funkcja jest sprawdzana na prawdziwej infrastrukturze i danych, zanim zobaczą ją klienci.
3. Termin premiery ustala biznes, bez nerwowego „wdrożenia o północy”.
4. Problem z nową funkcją rozwiązuje wyłączenie flagi, a nie awaryjny rollback całej aplikacji.

To podejście jest podstawą continuous delivery i trunk-based development, w którym wszyscy commitują często do głównej gałęzi, a niegotowy kod chronią flagi zamiast długo żyjących branchy.

Continuous delivery a continuous deployment

Te dwa terminy też bywają mylone, a różnica dotyczy właśnie deployu:

• Continuous delivery – każda zmiana po przejściu pipeline’u jest gotowa do wdrożenia, ale wdrożenie na produkcję zatwierdza człowiek.
• Continuous deployment – każda zmiana, która przejdzie testy, trafia na produkcję automatycznie.

W obu przypadkach release nadal może być kontrolowany osobno.

Techniki oddzielania wdrożenia od wydania

Feature flagi (feature toggles)

Flaga to warunek w kodzie, którego wartość pobierasz z konfiguracji lub zewnętrznej usługi w czasie działania aplikacji. Nowa ścieżka kodu jest wdrożona, ale wykona się tylko wtedy, gdy flaga jest włączona — dla wszystkich, dla wybranej grupy albo dla określonego procentu ruchu.

# Uproszczony przykład z biblioteką OpenFeature (Python)
from openfeature import api

client = api.get_client()

def koszyk(uzytkownik):
    nowy = client.get_boolean_value("nowy-koszyk", False)
    return nowy_koszyk(uzytkownik) if nowy else stary_koszyk(uzytkownik)

OpenFeature to otwarty standard API flag (projekt CNCF), pod który można podłączyć różnych dostawców, np. Unleash, Flagsmith, LaunchDarkly albo własny plik konfiguracyjny. Pamiętaj o sprzątaniu: każda flaga, która zrobiła swoje, powinna zostać usunięta z kodu, bo stare flagi szybko zamieniają się w dług techniczny.

Dark launch

Nowy kod działa na produkcji i przetwarza prawdziwy ruch, ale wyniki nie są pokazywane użytkownikom. Przykład: nowy silnik rekomendacji liczy podpowiedzi równolegle ze starym, a zespół porównuje wyniki i obciążenie. To sprawdzian wydajności przed właściwym wydaniem.

Canary release

Nowa wersja dostaje najpierw mały procent ruchu (np. 5%), a reszta trafia do starej. Jeśli metryki błędów i opóźnień są w normie, udział stopniowo rośnie do 100%. Kubernetes nie robi tego sam w podstawowym obiekcie Deployment — stosuje się do tego np. Argo Rollouts, Flagger albo reguły podziału ruchu w service mesh lub ingressie.

Zwróć uwagę, że canary to technika z pogranicza: technicznie jest to deploy, ale ponieważ część użytkowników już widzi zmianę, jest to też częściowy release.

Blue/green deployment

Utrzymujesz dwa identyczne środowiska. Na „blue” działa obecna wersja, na „green” wdrażasz nową i testujesz ją bez ruchu produkcyjnego. Release to przełączenie load balancera z blue na green, a rollback to przełączenie z powrotem. Koszt: przez pewien czas potrzebujesz podwójnej infrastruktury. Wdrożenia oparte na kontenerach znacznie to ułatwiają; różnicę między samymi kontenerami a ich orkiestracją opisuje artykuł Kubernetes vs Docker.

Rolling update

Domyślna strategia obiektu Deployment w Kubernetes: pody są wymieniane stopniowo, partiami, bez przestoju. To czysto techniczny sposób wdrożenia — gdy rollout się kończy, wszyscy użytkownicy dostają nową wersję, więc bez flag deploy jest tu jednocześnie releasem.

# Cofnięcie wdrożenia do poprzedniej rewizji
kubectl rollout undo deployment/sklep-web
# Odpowiednik w Helmie
helm rollback sklep 3

Jak to poukładać w małym zespole

Nie musisz od razu budować platformy z canary i service mesh. Rozsądna ścieżka wygląda tak:

1. Zautomatyzuj deploy, żeby był powtarzalny i nudny: pipeline CI/CD, który buduje artefakt i wdraża go jednym poleceniem lub kliknięciem. Przy serwerach bez Kubernetes świetnie sprawdza się Ansible.
2. Wersjonuj artefakty (tagi Git, numery obrazów) i nigdy nie wdrażaj tagu latest na produkcję — rollback wymaga wiedzy, do czego wracasz.
3. Wprowadź prostą flagę dla pierwszej większej funkcji, nawet w postaci zmiennej konfiguracyjnej.
4. Dopiero gdy wdrożeń jest dużo, dodaj stopniowe udostępnianie (canary lub procentowe flagi) i monitoring, który pozwoli ocenić, czy nowa wersja jest zdrowa.

Na rozmowach rekrutacyjnych na stanowiska DevOps pytanie „czym różni się deploy od release” pojawia się regularnie, obok pytań o kontenery — przykłady znajdziesz w zestawie pytań rekrutacyjnych o Dockera. Najkrótsza dobra odpowiedź brzmi: deploy dotyczy kodu w środowisku, release dotyczy funkcji u użytkownika, a dobre praktyki polegają na tym, żeby te dwa momenty dało się rozdzielić.