Deployment łatwo zaklasyfikować jako problem operacyjny rozpoczynający się po zakończeniu developmentu. W praktyce ścieżka release’u zmienia zachowanie inżynierskie długo przed produkcją.
W jednym projekcie MES release’y wymagały powtarzalnej ręcznej pracy przez RDP. Zbudowałem narzędzie deploymentowe drag-and-drop, które skróciło czas wdrożenia o około 95%.
Oczywistą korzyścią był czas. Ważniejszą była częstotliwość feedbacku.
Wolne release’y tworzą ukryte batchowanie
Gdy deployment jest drogi, inżynierowie naturalnie grupują więcej zmian w jednym releasie. Większe release’y są trudniejsze do zrozumienia, trudniejsze do przetestowania i trudniejsze do rollbacku.
Zmniejszenie tarcia release’owego wpływa więc na:
- rozmiar zmian;
- częstotliwość weryfikacji;
- pewność rollbacku;
- gotowość do wypuszczania małych poprawek;
- czas między feedbackiem klienta a korektą.
Automatyzuj powtarzalną granicę
Nie każde legacy environment potrzebuje pełnej platformy cloud-native. Czasem właściwą interwencją jest wąskie narzędzie, które zamienia istniejącą ścieżkę deploymentu w proces deterministyczny.
Celem nie jest modna infrastruktura. Celem jest release z mniejszą liczbą ręcznych odgałęzień i mniejszym promieniem rażenia.
Zasada praktyczna
Traktuj latencję deploymentu jako część pętli developmentu. Jeżeli wysyłanie zmian boli, architektura już nalicza odsetki od każdej kolejnej zmiany.