Na co zwracacie uwagę dołączając do nowego zespołu, by ocenić jego dojrzałość? Dojrzałość rozumianą jako gotowość do wzięcia odpowiedzialności za dostarczaną wartość biznesową. Można przyjrzeć się kulturze tego zespołu, procesowi wytwarzania wartości (ang. Way of working) itd. Z naszego doświadczenia, jednym z istotnych papierków lakmusowych dojrzałości zespołu DevOps (i stojącej za nim organizacji!) jest jego podejście do wdrożeń na produkcję. Ten wpis poświęcony jest różnicy między deploymentami a release’ami.
Deployment to po prostu wdrożenie nowej wersji (aplikacji, infrastruktury itp.) na produkcję. Release to z kolei udostępnienie nowej funkcjonalności klientom, która mogła wejść w przeszłości na produkcję z danym deploymentem. Za deployment odpowiedzialny jest zespół developerski. To on podejmuje decyzję, kiedy wykonać wdrożenie. Za release z kolei odpowiada osoba biznesowa, np. Product Owner. To ona decyduje, czy i kiedy funkcjonalność powinna ujrzeć światło dzienne dla użytkowników.
Jednym z objawów dojrzałości może być to, że częstotliwość deploymentów jest znacząco większa niż release’ów. Może to sugerować, że zespół nie szuka wymówek, dlaczego nie wdraża często na produkcję, chowając się za kalendarzem biznesowym aplikacji, tylko faktycznie wykorzystuje częstą pętlę zwrotną z produkcji do optymalizacji codziennej pracy. Jaka to informacja zwrotna? Jeśli tzw. delta zmian na produkcję jest mała (a przez to złożoność wdrażanej zmiany jest mała), dajemy sobie jako zespół częściej szansę na to, by wcześnie zidentyfikować, że nasza zmiana
Przeczytaj także: Co to jest DevOps?
Jedną z technik są tzw. feature toggle (zwane również: feature switch, feature flag itd.), za pomocą których jesteśmy w stanie schować daną nie w pełni zaimplementowaną funkcjonalność przed użytkownikami. Można ją również udostępnić tylko zaufanym osobom na produkcji: interesariuszom, przedstawicielom biznesu, pracownikom naszej firmy itd. Intencją jest to, aby otrzymać feedback z produkcji bez negatywnych konsekwencji biznesowych dla naszej firmy.
Oznacza to, że zespół deweloperski z małym ryzykiem wdraża bardzo często zmiany na produkcję z feature togglem chowającym funkcjonalność dla wszystkich lub prawie wszystkich. Gdy Product Owner czuje się już komfortowo z tym, na jakim poziomie jest zaimplementowana funkcjonalność, zmienia wartość flagi, aby udostępnić nową funkcjonalność wszystkim użytkownikom.
Odpowiedź na to pytanie jest zbyt długa, na krótki post na bloga.
Jeśli jednak nadal nie jest przekonana/-y, ponieważ cykl deploymentu w Twojej firmie trwa tygodniami lub miesiącami, w który jest zaangażowane wiele zespołów, to najprawdopodobniej jest to o tym, że architektura Twojego systemu nie wspiera autonomicznych zespołów, które nie mogą zarządzać swoimi deploymentami niezależnie od innych. Innymi słowy, najprawdopodobniej ograniczenia wynikające z architektury wymuszają stawianie znaku równości między deploymentem a releasem. A to oznacza, że podczas deploymentu testujemy i nową funkcjonalność, i regresję, i bezpieczeństwo, i performance.