Wyobraź sobie, że planujesz wakacje.
Masz bilet, walizkę, lecicie gdzieś daleko — wszystko musi zadziałać jak w zegarku.
Więc by wszystko zachowało się zawsze zgodnie z założonym planem wyobraź sobie, że lotnisko to nic innego jak pipeline CI/CD.
Dobra, ale co w ogóle oznacza ten skrót CI/CD?
CI – Continuous Integration
To tak naprawdę wszelkie prace związane z weryfikacją i poprawnością kodu, a także przygotowaniem do późniejszego wypchnięcia ich na środowisko.
Więc w przypadku naszego przykładu zaczynamy od przygotowania do lotu.
Każdy samolot czyli commit - wrzucenie zmian do repozytorium przez programistę (może być to mała zmiana w kodzie, dodanie całej funkcjonalności itd.) przed startem musi przejść dokładne kontrole:
1. Przegląd techniczny – czy wszystko działa jak trzeba?
→ W CI oznacza to budowanie aplikacji i testy jednostkowe.
2. Tankowanie paliwa – przygotowanie zasobów potrzebnych do działania.
→ W pipeline to instalacja zależności, pobieranie bibliotek, budowanie obrazu Docker.
3. Kontrola dokumentów i bezpieczeństwa – zanim samolot poleci, trzeba mieć pewność, że wszystko jest legalne i bezpieczne.
→ W CI to linting, security scan, SAST – czyli automatyczne sprawdzenie, czy nie wkradły się błędy lub podatności.
W CI chodzi o to, żeby każdy samolot był sprawny, zanim ruszy z hangaru. Sprawdzamy, czy nowe części (czyli kod) nie popsuły silnika, czy wszystko jest zatankowane i gotowe do drogi.
CD – Continuous Delivery / Continuous Deployment
No dobrze – samolot przeszedł wszystkie kontrole, czyli czas na wypchnięcie go z hangaru– czyli wdrożenie nowej wersji aplikacji.
Tutaj rozróżniamy dwie opcje:
Opcja 1 - Continuous Delivery
To sytuacja, gdy samolot stoi już na pasie startowym, gotowy do lotu.
Silniki pracują, pasażerowie siedzą, ale pilot czeka na pozwolenie z wieży. Oznacza to, że wdrożenie jest przygotowane, ale uruchamiane ręcznie.
Opcja 2 - Continuous Deployment
A to już lotnisko w pełni zautomatyzowane.
Każdy samolot, który przeszedł kontrolę techniczną, sam startuje – bez czekania na człowieka, tak jakbyśmy mieli samoloty bezzałogowe. To w pełni automatyczny deploy na produkcję po udanym buildzie i testach.
Podsumowując
Continuous Delivery to lot gotowy do startu, ale czeka na zgodę. Continuous Deployment to samolot, który sam startuje, gdy tylko wszystko działa.
Jak wygląda to w przypadku pliku?
Jak wygląda to w przypadku pliku pipeline, w którym definiujemy kroki naszego CI/CD - tak definiujemy to jako kod w plikach YML.
Przedstawmy to na przykładzie pipeline z GitHub Actions:
name: Short Flight CI/CD
on:
push:
branches: [ "main" ] # Nowy „lot” po pushu na main
workflow_dispatch: # Opcjonalny start ręczny
jobs:
ci_preflight: # CI — przegląd samolotu
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4 # Pobierz kod (samolot z hangaru)
- uses: actions/setup-python@v5 # To jakby włączenie pokładowych systemów
# zanim zaczniemy właściwą kontrolę techniczną
with: { python-version: "3.11" }
- run: pip install -r requirements.txt # Tankowanie samolotu i wsadzanie walizek
- run: pytest -q # Testy przedlotowe
cd_takeoff: # CD — start na produkcję
needs: ci_preflight
runs-on: ubuntu-latest
environment: production # wszystkie systemy sprawdzone i pilot (czyli pipeline)
# czeka na sygnał z wieży kontroli lotów
steps:
- run: echo "Deploying..." Po kliknięciu Approve samolot startuje, czyli wdrażamy kod na produkcję.
Po co to wszystko?
Żebyś nie musiał ręcznie popychać samolotu.
CI/CD sprawia, że Twoje wdrożenia są:
- • powtarzalne (każdy samolot przechodzi te same kontrole),
- • szybkie (nie czekasz na pilota),
- • bezpieczne (nikt nie wystartuje bez przeglądu technicznego),
- • bezstresowe (bo wszystko dzieje się automatycznie).
Podsumowanie
Następnym razem, gdy będziesz siedział w samolocie i patrzył, jak obsługa techniczna robi swoje, pomyśl, że dokładnie to samo dzieje się z Twoim kodem, zanim trafi na produkcję.
I że dzięki CI/CD możesz być spokojny – każdy lot Twojej aplikacji będzie bezpieczny, sprawdzony i dokładnie zaplanowany.