Co to jest ITIL®? Wszystko o zarządzaniu usługami IT
ITIL to uznany na całym świecie zbiór najlepszych praktyk zarządzania IT. Przeczytaj o najważniejszych koncepcjach i komponentach najnowszej wersji ITIL 4. czytaj dalej
Jaka jest różnica między deploymentem a releasem?
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.
O jakiej dojrzałości można zatem mówić w kontekście deploymentów i release’ó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
- nie wprowadza na produkcję błędów regresji w istniejących funkcjonalnościach
- nie osłabia bezpieczeństwa naszego rozwiązania
- nie osłabia wydajności naszego rozwiązania
- (i równie ważne) wprowadza częściowo zaimplementowaną nową funkcjonalność (np. w obszarze happy path) działającą na produkcji poprawnie dla zaufanych użytkowników (tzw. friends and family)
Przeczytaj także: Co to jest DevOps?
Jak to osiągnąć?
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.
Jak to robić w regulowanym środowisku (np. PCI-DSS)?
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.
