CI/CD

Example

Jak działa ten proces krok po kroku:

Development

Master branch (GitHub) — mamy główną gałąź kodu (master).
Developer pobiera kod (pull down) i tworzy lokalną gałąź funkcjonalną (feature branch).
W tej gałęzi wprowadza zmiany, rozwija funkcję i wykonuje commit.

Pull Request (PR)

Po zakończeniu prac developer tworzy Pull Request (prośba o włączenie zmian do master).
PR przechodzi do etapu Peer Review.

Peer Review

Kod w PR jest recenzowany przez innych developerów (Peer Code Review).
Automatyczne narzędzia wykonują:
Bug check — wykrywanie potencjalnych błędów.
Security analysis — analiza bezpieczeństwa kodu.
Passing bullets (prawdopodobnie chodzi o testy jednostkowe / integracyjne, które muszą przejść).
Jeśli wszystko jest OK, zmiany trafiają do gałęzi master.

QA (Quality Assurance)

Zaktualizowany master jest przekazywany do środowiska QA.
QA Testing — testerzy wykonują testy funkcjonalne, regresyjne, eksploracyjne itp.
User bug analysis — zgłaszane błędy są analizowane.
Ponownie odbywa się Security analysis (być może w kontekście środowiska QA).

Pre-Prod

Kod po QA jest automatycznie wdrażany (Auto Deploy) na środowisko Pre-Production.
Tu działa Load Balancer kierujący ruch do dwóch stref dostępności (Availability Zone A) z bazami danych.

Production

Po weryfikacji w Pre-Prod kod jest automatycznie wdrażany na środowisko Production (AWS).
Ponownie jest Load Balancer + kilka stref dostępności dla wysokiej dostępności systemu.

Snapshot Backups

Po wdrożeniu produkcyjnym robione są snapshoty baz danych w celu backupu.

Problemy w schemacie

Brak zaznaczenia testów automatycznych po stronie QA – jest mowa o testach w Peer Review, ale w CI/CD zwykle testy automatyczne są też w pipeline przed QA.
Niejasne “Passing bullets” — nie jest to standardowe określenie, może wprowadzać w błąd.
Brak oznaczenia środowisk DEV / QA / PRE-PROD / PROD w jednym ciągłym przebiegu — teraz wygląda jak trzy równoległe bloki.
Strzałki są mało intuicyjne — w niektórych miejscach zawracają w sposób mylący.