CI/CD i automatyzacja
Wdrożenie ma być nudne
Jeśli release oznacza u Was nerwy, nadgodziny i „nie deployujemy w piątki” — to nie jest dojrzałość procesu, tylko brak automatyzacji. Budujemy i porządkujemy pipeline’y CI/CD, po których wdrożenie to przycisk, a wycofanie zmiany — drugi przycisk.
Zakres prac
Pipeline od zera albo porządkowanie istniejącego
GitLab CI i GitHub Actions: build, testy, artefakty, wdrożenie na stage i produkcję. Przejmujemy też pipeline’y odziedziczone — takie, których „nikt nie rusza, bo działa”.
Infrastruktura jako kod
Ansible do konfiguracji, Terraform do zasobów. Środowisko da się odtworzyć z repozytorium, a różnice między stage i produkcją przestają być folklorem.
Strategia wdrożeń i rollback
Wdrożenia bez przerwy w działaniu tam, gdzie architektura na to pozwala; wszędzie — jasna, przećwiczona ścieżka wycofania. Rollback testujemy tak samo jak deploy.
Sekrety i dostępy
Koniec z hasłami w zmiennych pipeline’u wpisanymi na stałe i kluczami w repozytorium. Porządkujemy zarządzanie sekretami i dostępy per środowisko.
Jak wygląda projekt CI/CD
- Audyt procesu wdrożeń — od commita do produkcji, z pomiarem czasu i punktów ręcznych.
- Plan i wycena — co automatyzujemy, w jakiej kolejności, co zostawiamy, bo się nie opłaca.
- Wdrożenie etapami — zaczynamy od najbardziej bolesnego kroku; Twój zespół używa pipeline’u od pierwszego tygodnia.
- Przekazanie — dokumentacja w repo i warsztat dla zespołu. Pipeline, którego nikt nie rozumie, to nowy dług, nie postęp.
Uczciwie
- Nie wciskamy Kubernetesa firmie z trzema VPS-ami. Narzędzie ma pasować do skali, nie do mody.
- Automatyzujemy tylko to, co się zwraca — resztę wskażemy jako „zostawić”.
- Projekt CI/CD często kończy się abonamentem utrzymania produkcji — ale nie musi.