Zespoły IT, które nie mają ustalonego flow wdrożeń, zwykle nie narzekają na brak narzędzi. Narzekają na to, że wydanie zmiany trwa nieprzewidywalnie długo, a każde wdrożenie wymaga obecności jednej konkretnej osoby.
Objawy braku procesu
- Wdrożenia odbywają się wieczorem albo w piątek, bo „wtedy jest spokój”.
- Nikt nie potrafi powiedzieć, co dokładnie znajduje się teraz na produkcji.
- Powrót do poprzedniej wersji jest operacją ręczną i stresującą.
- Testy istnieją, ale nie są warunkiem wypuszczenia zmiany.
Kolejność, która się sprawdza
Porządkowanie warto prowadzić etapami, bo każdy etap daje efekt sam z siebie i nie wymaga ukończenia całości.
1. Jedno źródło prawdy w repozytorium. Ustalona strategia gałęzi, jasne zasady scalania, obowiązkowy przegląd kodu. Bez tego automatyzacja tylko szybciej rozniesie bałagan.
2. Automatyczna weryfikacja. Budowanie i testy uruchamiane przy każdej zmianie, z jednoznacznym wynikiem: przechodzi albo nie przechodzi.
3. Powtarzalne wdrożenie. Ta sama komenda albo ten sam przycisk dla każdego środowiska. Wdrożenie przestaje być wydarzeniem.
4. Widoczność i wycofywanie zmian. Wiadomo, co i kiedy zostało wypuszczone, i jak w kilka minut wrócić do wersji poprzedniej.
Czego się spodziewać po stronie zespołu
Największy opór nie dotyczy technologii, ale zmiany nawyków. Obowiązkowy przegląd kodu bywa odbierany jako brak zaufania, a automatyczne testy jako spowolnienie pracy. Warto o tym mówić wprost i pokazywać, że celem jest zdjęcie z ludzi odpowiedzialności za ręczne pilnowanie wszystkiego.
Jak zmierzyć, że działa
Wystarczą dwie liczby: ile czasu mija od gotowej zmiany do jej pojawienia się na produkcji oraz ile wdrożeń trzeba było wycofać. Jeśli pierwsza spada, a druga się nie zwiększa, proces działa w dobrym kierunku.