DevOps to kultura i zestaw praktyk łączących development (programowanie) z operations (administracja serwerami) – dzięki czemu kod od napisania do produkcji trafia w minuty zamiast tygodni. CI/CD (Continuous Integration / Continuous Deployment) to rdzeń DevOps: automatyczne testowanie, budowanie i wdrażanie kodu po każdej zmianie. Zamiast: programista pisze kod → tygodnie testów ręcznych → admin ręcznie wgrywa na serwer przez FTP – masz: push kodu do GitHub → automatyczne testy → automatyczny deploy → zmiana jest live w 5 minut.
Co to jest DevOps
Tradycyjnie: programiści pisali kod i „rzucali przez mur” do adminów, którzy wdrażali go na serwerze. Problemy: „u mnie działa” (różnice między środowiskiem dev i prod), wolne wdrożenia (raz na miesiąc/kwartał), blame game (dev wini ops, ops wini dev). DevOps łączy te dwa światy – jeden zespół odpowiada za cały cykl: napisanie kodu, testowanie, wdrożenie, monitoring, naprawianie.
Filary DevOps: automatyzacja (wszystko, co się powtarza, powinno być zautomatyzowane), CI/CD (ciągła integracja i wdrażanie), Infrastructure as Code (serwery konfigurowane kodem, nie ręcznie), monitoring i alerting (wykrywanie problemów zanim zauważą je użytkownicy), feedback loops (szybka informacja zwrotna z produkcji).
CI – Continuous Integration
Continuous Integration to praktyka, w której każdy programista kilka razy dziennie merguje swój kod do wspólnego repozytorium, a po każdym mergeu automatycznie uruchamiają się testy. Workflow: programista push’uje kod na branch → otwiera pull request → CI automatycznie: pobiera kod, instaluje zależności, uruchamia testy (unit, integration), sprawdza linting/formatowanie, buduje projekt. Jeśli testy przejdą: zielony znaczek ✅ na PR. Jeśli nie: czerwony ✗ z logami błędu. Code review + CI pass = merge do main.
Bez CI: programista push’uje kod → nikt nie sprawdza czy działa → po tygodniu merge → produkcja się sypie. Z CI: każda zmiana jest testowana automatycznie – błędy łapane w minutach, nie tygodniach.
CD – Continuous Deployment
Continuous Deployment to automatyczne wdrażanie kodu na produkcję po przejściu CI. Merge do main → CI buduje + testuje → CD deploy’uje na serwer → zmiana jest live. Zero ręcznej interwencji. Wariant łagodniejszy: Continuous Delivery – kod jest gotowy do deploy’u po CI, ale wymaga ręcznego kliknięcia „Deploy” (dla firm, które chcą kontrolę nad momentem wdrożenia).
Narzędzia CI/CD
| Narzędzie | Typ | Najlepsze do |
|---|---|---|
| GitHub Actions | Cloud (wbudowane w GitHub) | Projekty na GitHub, open source |
| GitLab CI | Cloud / self-hosted | GitLab users, enterprise, self-hosted |
| Jenkins | Self-hosted (open source) | Enterprise, złożone pipeline’y, legacy |
| CircleCI | Cloud | Szybkie buildy, Docker-native |
| Bitbucket Pipelines | Cloud (Atlassian) | Zespoły na Jira/Confluence |
GitHub Actions to najprostszy start: definiujesz workflow w pliku YAML (.github/workflows/deploy.yml), a GitHub uruchamia go na hostowanym runnerze (Ubuntu). 2 000 darmowych minut/mc na darmowym koncie.
Przykład pipeline CI/CD
# .github/workflows/deploy.yml
name: CI/CD Pipeline
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 20
- run: npm ci
- run: npm test
- run: npm run lint
deploy:
needs: test
if: github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci && npm run build
- name: Deploy to server
run: rsync -avz ./dist/ user@serwer:/var/www/html/
env:
SSH_KEY: ${{ secrets.SSH_PRIVATE_KEY }}Push na main lub PR → job test: instalacja, testy, linting. Jeśli testy OK + branch main → job deploy: build + rsync na serwer. Cały pipeline: 1–5 minut.
Infrastructure as Code (IaC)
Zamiast ręcznie konfigurować serwery (kliknij tu, wpisz tam) – opisujesz infrastrukturę w kodzie i narzędzie ją automatycznie tworzy. Terraform – tworzenie infrastruktury cloud (AWS, Azure, GCP): serwery, sieci, bazy danych, DNS – deklaratywnie w plikach .tf. Ansible – konfiguracja serwerów (instalacja pakietów, konfiguracja Nginx, deploy aplikacji) – playbooki w YAML. Docker – konteneryzacja aplikacji (Dockerfile opisuje środowisko, docker-compose.yml uruchamia stos).
Zalety IaC: powtarzalność (ten sam skrypt = identyczne środowisko za każdym razem), wersjonowanie (konfiguracja w Git – historia zmian, rollback), szybkość (nowy serwer w minuty zamiast godzin).
DevOps a WordPress / strony
DevOps nie jest tylko dla dużych aplikacji – nawet strona na WordPressie korzysta z praktyk DevOps. Motyw i wtyczki custom w repozytorium Git. Środowisko staging (kopia strony do testów). CI: po push’u – testy PHP (PHPUnit), linting, build CSS/JS. CD: automatyczny deploy na serwer (rsync, SSH) lub aktualizacja przez WP-CLI. Backup automatyczny (cron + offsite storage).
Najczęściej zadawane pytania
Czy DevOps to stanowisko czy metodyka?
Oba. DevOps to przede wszystkim kultura i zestaw praktyk (automatyzacja, CI/CD, współpraca dev+ops). Ale: istnieje stanowisko „DevOps Engineer” – osoba odpowiadająca za: pipeline’y CI/CD, konfigurację serwerów (IaC), monitoring, konteneryzację (Docker, Kubernetes), bezpieczeństwo infrastruktury.
Czy potrzebuję DevOps dla małego projektu?
Nie potrzebujesz „pełnego DevOps” (Kubernetes, Terraform, 20 mikroserwisów). Ale: nawet dla małego projektu warto: trzymać kod w Git, mieć CI (testy automatyczne na każdym PR), mieć prosty CD (automatyczny deploy po mergeu do main). GitHub Actions + rsync: 15 minut konfiguracji, a oszczędza godziny ręcznego wgrywania przez FTP.
DevOps vs SRE – jaka różnica?
DevOps to kultura i praktyki (CI/CD, automatyzacja, współpraca). SRE (Site Reliability Engineering) to implementacja DevOps stworzona przez Google – z konkretnymi narzędziami: SLO (Service Level Objectives), error budgets, toil reduction. SRE jest bardziej „operacyjny” (focus na niezawodności produkcji), DevOps bardziej „kulturowy” (focus na współpracy dev/ops). W praktyce: dużo się pokrywają.
