„Działaj szybko” i „nie psuj produkcji” kłócą się ze sobą tylko wtedy, gdy wydania są duże, nieprzejrzyste i nieodwracalne. Regularne wdrażanie to bardziej kwestia praktyki niż narzędzi.
Inżynieria produktu w rosnących zespołach polega na godzeniu obietnic składanych klientom z techniczną rzeczywistością. Najszybsze wydają się często te zespoły, które codziennie wypuszczają małe zmiany i potrafią dokładnie powiedzieć, co się zmieniło.
Małe porcje zamiast wielkiego wybuchu
Feature flag nie zastąpi dzielenia pracy na mniejsze części. Chodzi o to, by wartość trafiała do głównej gałęzi bez przerwy: zmiany schematu zgodne wstecz, interfejs za flagą tylko wtedy, gdy to konieczne, i migracje, które można uruchomić przed kodem, który od nich zależy.
Niech wycofanie zmian wejdzie w pamięć mięśniową
Jeśli cofnięcie wdrożenia wymaga sztabu kryzysowego, będziesz wdrażać rzadziej. Instrukcje operacyjne, health checki i artefakty wdrożeniowe powinny zakładać, że wycofywanie zmian zdarza się regularnie, a nie tylko podczas katastrof.
- Jedna logiczna zmiana na wydanie, gdy tylko się da.
- Automatyczne smoke testy na ścieżkach, które przynoszą przychód albo generują zgłoszenia do wsparcia.
- Obserwowalność błędów i opóźnień powiązana ze znacznikami wydań.
Regularność to nie mniej wydań. To przewidywalne wydania ze znanym zasięgiem rażenia.
Komunikacja jest częścią systemu
Zarówno narzędzia wewnętrzne, jak i produkty dla klientów zawodzą, gdy zaskoczeni są ci, którzy je obsługują. Krótkie informacje o wydaniu, widoczne changelogi dla administratorów i środowiska stagingowe odwzorowujące ograniczenia produkcji sprawiają, że przy starcie rzadziej pada „u mnie działa”.
Tak pracujemy przy projektach klientów i własnych produktach; krok po kroku opisujemy to w tekście o tym, jak budujemy produkty.
Regularne wdrażanie pozwala firmie rosnąć bez strachu przed własnym oprogramowaniem. Te praktyki są mało efektowne, ale ich efekt (zespoły, które co tydzień ulepszają produkt bez dramatów) już taki nie jest.