Opublikowano · Zaktualizowano
Deployment powinien być nudny
W ConnectTo, gdzie jako junior zaczynałem komercyjną pracę z Laravelem, wdrożenie polegało na uruchomieniu git pull na serwerze produkcyjnym. Zdarzało się, że konflikty merge rozwiązywano właśnie tam, więc produkcja mogła się różnić i od repozytorium, i od lokalnej kopii każdego z developerów.
- CI/CD
- deployment
- Git
- Docker
- GitHub Actions
- GitLab CI
Co było nie tak z git pull na produkcji
Wdrożenie zależało od tego, czy ktoś pamięta kolejność komend i aktualny stan serwera. Z samego commita nie dało się tego wyczytać.
Rozwiązanie konfliktu na produkcji zmieniało też working tree w trakcie wdrożenia. Na serwerze mógł wtedy działać wynik merge, którego nikt wcześniej nie sprawdził ani nie odtworzył w innym środowisku.
Miałem dostęp do produkcji i pomagałem przy wdrożeniach w zespole trzech developerów. Stąd wzięło się moje przekonanie do CI/CD.
Kroki wdrożenia w repozytorium
W późniejszych projektach używałem GitHub Actions i GitLab CI do powtarzalnych kroków build i deploy, a Dockera tam, gdzie pasował do środowiska docelowego. W GitHub Actions wyglądało to zwykle tak: build obrazu, push do registry i deploy tego samego obrazu. Komendy i ich kolejność są w wersjonowanej konfiguracji, a nie w historii czyjegoś terminala.
- Buduj artefakt, który faktycznie zostanie wdrożony.
- Trzymaj komendy wdrożenia w wersjonowanej konfiguracji pipeline’u.
- Uruchamiaj automatyczne kontrole przed zmianą na produkcji.
- Ponowne wdrożenie i rollback nie mogą zależeć od historii czyjegoś terminala.
Co się zmieniło
Standardowe wdrożenia przestały wymagać rozwiązywania konfliktów na serwerze. Konfiguracja pipeline’u pokazuje, jakie kroki się wykonają, a log pokazuje, gdzie zatrzymało się nieudane wdrożenie. To właśnie rozumiem przez nudny deployment: wdrożenie nie może zależeć od wiedzy, którą ma tylko jedna osoba.