SAFe. Continous Delivery Pipeline
SAFe. Continous Delivery Pipeline
Podstawowym celem wszystkich konfiguracji dostarczanych przez SAFe jest tworzenie wysoce wydajnych fabryk z rzeczywistymi "rurociągami" produkcyjnymi zapewniającymi zrównoważony i ciągły przepływ wartości o najlepszej wydajności ekonomicznej, w jak najkrótszym czasie, ze stałą uwagą w celu eliminacji strat i opóźnień.
14 kwi 2020
1048
Other articles
Testowanie aplikacji za pomocą JUnit5 i JMock. Część 2
Jak przygotować się do certyfikacji IIBA. Wyzwania i hacki
Testowanie aplikacji za pomocą JUnit5 i Mockito. Część 2
Testowanie aplikacji za pomocą JUnit5 i Mockito. Część 1
Testowanie aplikacji za pomocą JUnit5 i EasyMock. Część 2
Testowanie aplikacji za pomocą JUnit5 i EasyMock. Część 1
Test Driven Development z użyciem JUnit 5. Część 6
Test Driven Development z użyciem JUnit 5. Część 5
Test Driven Development z użyciem JUnit 5. Część 4
Test Driven Development z uzyciem JUnit 5. Czesc 3
Podstawowym celem wszystkich konfiguracji dostarczanych przez SAFe jest tworzenie wysoce wydajnych fabryk z rzeczywistymi "rurociągami" produkcyjnymi zapewniającymi zrównoważony i ciągły przepływ wartości o najlepszej wydajności ekonomicznej, w jak najkrótszym czasie, ze stałą uwagą w celu eliminacji strat i opóźnień.
W tym momencie możemy już podkreślić fakt, że głównym celem wszystkich konfiguracji dostarczanych przez SAFe jest tworzenie wysoce wydajnych fabryk z prawdziwymi "rurociągami" produkcyjnymi zapewniającymi zrównoważony i ciągły przepływ wartości o najlepszej wydajności ekonomicznej, w najkrótszym czasie czas ze stałą uwagą na eliminację strat i opóźnień.
Jest to najlepiej widoczne, jeśli spojrzymy na konfigurację programu, w której Agile Release Train jest zorganizowany dokładnie wokół idei wdrożenia koncepcji ciągłej dostawy z czterema podprocesami:
Element Ciągłej Eksploracji jest prowadzony głównie przez PM, którzy współpracują z klientami w celu zaspokojenia ich potrzeb, analizują badania rynku i handlu oraz inne źródła informacji. Współpracują również z architektami w celu zdefiniowania najlepszego rozwiązania technicznego do realizacji tych potrzeb i syntetyzują całą tę pracę w Vision, Roadmap i priorytetowej liście Features, które mają zostać wdrożone przez zespoły w pociągach.
Proces Ciągłej Integracji to praca wykonywana przez zespoły w celu podzielenia funkcji na historie użytkowników, wdrożenia tych historii, ciągłej integracji każdego pionowego segmentu nowej funkcjonalności, przetestowania go, a także integracji z pracą wszystkich innych zespołów w celu ponownego zgromadzenia Stories w Features. W tym punkcie PM mogą potwierdzić początkowe założenia. Ogromny wkład ma automatyzacja uruchamiania zestawów testowych w środowiskach pomostowych emulujących produkcję.
W odniesieniu do ciągłego wdrażania, SAFe przyjmuje inne podejście od poprzedniego wspólnego zrozumienia, które, krótko mówiąc, oznaczało, że powinieneś dostarczać do produkcji w sposób ciągły, bez względu na to, czy tobie, czy klientom to się podoba, czy nie, lub jesteś na to przygotowany. W SAFe wdrożenie jest całkowicie oddzielone od wydania.
Ciągłe Wdrażanie to proces, który obsługuje sprawdzanie poprawności nowego przyrostu systemu w środowiskach, które są w 100%, jeśli to możliwe, podobne do rzeczywistych środowisk produkcyjnych. Te środowiska wdrażania mogą w niektórych przypadkach być dokładnie środowiskami produkcyjnymi, ale nie oznacza to, że nowe wdrożone funkcje są natychmiast dostępne do rzeczywistego użycia.
Nowe Features są sprawdzane osobno w tych środowiskach, w połączeniu z resztą nowych dodanych elementów i sprawdzania, czy nie psują również starszych funkcji. Jeśli wdrożenie odbywa się w rzeczywistych środowiskach produkcyjnych, istnieją techniki takie jak "feature toggles", "canary releases" i "dark launches", które "ukrywają" nową funkcjonalność przed zdecydowaną większością użytkowników, pozwalając na testowanie w prawdziwym świecie, ale w kontrolowanych warunkach.
Praca na bardzo skomplikowanych systemach oznacza, że wydanie jest czasem krokiem, który wymaga widocznej pracy, takiej jak zbudowanie pakietu, aktualizacja dokumentacji, przeszkolenie użytkowników, uzyskanie akceptacji dla aspektów takich jak zgodność i tak dalej. Oznacza to, że ciągła dostawa nie jest możliwa w większości przypadków.
Każda organizacja musi jednak być w stanie zainicjować proces wydania, gdy nadejdzie żądanie. Dlatego modelowanie podprocesu "Wydanie na Żądanie" jest koniecznością dla wszystkich organizacji, a wszystkie trzy poprzednie podelementy powinny wspierać tę zdolność i sprawić, by była jak najbardziej płynna i wydajna.
Jednym z głównych celów każdego programu SAFe powinna być pełna automatyzacja "rurociągu" ciągłego dostarczania związanego z każdym aspektem, od integracji i testowania do udostępniania i wdrażania środowiska.
Trwa długa dyskusja na temat roli Scrum Masters w Agile. Wszystkie obowiązki, cechy i funkcje obowiązują również w SAFe. A ponieważ zespół Agile prawie nigdy nie jest niezależny, w SAFe jest to jeszcze bardziej oczywiste. Zespół powinien być zdolny do samodzielnej pracy przez większość czasu, ale zawsze mając na uwadze zależności z innymi zespołami w pociągu.
Tak więc funkcja i obowiązki SM mają powiązania rozciągające się na zewnątrz na prawie każdą inną rolę, ceremonię i proces w SAFe. A ponieważ ktoś musi się upewnić, że "mechanizmy" pociągu działają z najwyższą wydajnością, nowa rola została zdefiniowana specjalnie do wykonywania pracy Scrum Master, ale na poziomie Programu. Rolą tą jest Inżynier ds. Uwolnienia Pociągu działający jako Główny SM dla całego pociągu obsługującego procesy Programu. Ta postać jest głównym punktem eskalacji dla SM każdej drużyny, jest głównym organizatorem ceremonii na poziomie programu, pomaga w usuwaniu przeszkód dla całego pociągu, działa jako trener SAFe i tak dalej.
Iulian Velea
Technical Project Manager | Certyfikowany konsultant programu SAFe (SPC4)
W tym momencie możemy już podkreślić fakt, że głównym celem wszystkich konfiguracji dostarczanych przez SAFe jest tworzenie wysoce wydajnych fabryk z prawdziwymi "rurociągami" produkcyjnymi zapewniającymi zrównoważony i ciągły przepływ wartości o najlepszej wydajności ekonomicznej, w najkrótszym czasie czas ze stałą uwagą na eliminację strat i opóźnień.
Jest to najlepiej widoczne, jeśli spojrzymy na konfigurację programu, w której Agile Release Train jest zorganizowany dokładnie wokół idei wdrożenia koncepcji ciągłej dostawy z czterema podprocesami:
- Ciągła Eksploracja
- Ciągła Integracja
- Ciągłe Wdrażanie
- Wydanie na Żądanie
Element Ciągłej Eksploracji jest prowadzony głównie przez PM, którzy współpracują z klientami w celu zaspokojenia ich potrzeb, analizują badania rynku i handlu oraz inne źródła informacji. Współpracują również z architektami w celu zdefiniowania najlepszego rozwiązania technicznego do realizacji tych potrzeb i syntetyzują całą tę pracę w Vision, Roadmap i priorytetowej liście Features, które mają zostać wdrożone przez zespoły w pociągach.
Proces Ciągłej Integracji to praca wykonywana przez zespoły w celu podzielenia funkcji na historie użytkowników, wdrożenia tych historii, ciągłej integracji każdego pionowego segmentu nowej funkcjonalności, przetestowania go, a także integracji z pracą wszystkich innych zespołów w celu ponownego zgromadzenia Stories w Features. W tym punkcie PM mogą potwierdzić początkowe założenia. Ogromny wkład ma automatyzacja uruchamiania zestawów testowych w środowiskach pomostowych emulujących produkcję.
W odniesieniu do ciągłego wdrażania, SAFe przyjmuje inne podejście od poprzedniego wspólnego zrozumienia, które, krótko mówiąc, oznaczało, że powinieneś dostarczać do produkcji w sposób ciągły, bez względu na to, czy tobie, czy klientom to się podoba, czy nie, lub jesteś na to przygotowany. W SAFe wdrożenie jest całkowicie oddzielone od wydania.
Ciągłe Wdrażanie to proces, który obsługuje sprawdzanie poprawności nowego przyrostu systemu w środowiskach, które są w 100%, jeśli to możliwe, podobne do rzeczywistych środowisk produkcyjnych. Te środowiska wdrażania mogą w niektórych przypadkach być dokładnie środowiskami produkcyjnymi, ale nie oznacza to, że nowe wdrożone funkcje są natychmiast dostępne do rzeczywistego użycia.
Nowe Features są sprawdzane osobno w tych środowiskach, w połączeniu z resztą nowych dodanych elementów i sprawdzania, czy nie psują również starszych funkcji. Jeśli wdrożenie odbywa się w rzeczywistych środowiskach produkcyjnych, istnieją techniki takie jak "feature toggles", "canary releases" i "dark launches", które "ukrywają" nową funkcjonalność przed zdecydowaną większością użytkowników, pozwalając na testowanie w prawdziwym świecie, ale w kontrolowanych warunkach.
Praca na bardzo skomplikowanych systemach oznacza, że wydanie jest czasem krokiem, który wymaga widocznej pracy, takiej jak zbudowanie pakietu, aktualizacja dokumentacji, przeszkolenie użytkowników, uzyskanie akceptacji dla aspektów takich jak zgodność i tak dalej. Oznacza to, że ciągła dostawa nie jest możliwa w większości przypadków.
Każda organizacja musi jednak być w stanie zainicjować proces wydania, gdy nadejdzie żądanie. Dlatego modelowanie podprocesu "Wydanie na Żądanie" jest koniecznością dla wszystkich organizacji, a wszystkie trzy poprzednie podelementy powinny wspierać tę zdolność i sprawić, by była jak najbardziej płynna i wydajna.
Jednym z głównych celów każdego programu SAFe powinna być pełna automatyzacja "rurociągu" ciągłego dostarczania związanego z każdym aspektem, od integracji i testowania do udostępniania i wdrażania środowiska.
Wdrożeniowa rola inżyniera pociągu i Scrum Mastera w SAFe
Trwa długa dyskusja na temat roli Scrum Masters w Agile. Wszystkie obowiązki, cechy i funkcje obowiązują również w SAFe. A ponieważ zespół Agile prawie nigdy nie jest niezależny, w SAFe jest to jeszcze bardziej oczywiste. Zespół powinien być zdolny do samodzielnej pracy przez większość czasu, ale zawsze mając na uwadze zależności z innymi zespołami w pociągu.
Tak więc funkcja i obowiązki SM mają powiązania rozciągające się na zewnątrz na prawie każdą inną rolę, ceremonię i proces w SAFe. A ponieważ ktoś musi się upewnić, że "mechanizmy" pociągu działają z najwyższą wydajnością, nowa rola została zdefiniowana specjalnie do wykonywania pracy Scrum Master, ale na poziomie Programu. Rolą tą jest Inżynier ds. Uwolnienia Pociągu działający jako Główny SM dla całego pociągu obsługującego procesy Programu. Ta postać jest głównym punktem eskalacji dla SM każdej drużyny, jest głównym organizatorem ceremonii na poziomie programu, pomaga w usuwaniu przeszkód dla całego pociągu, działa jako trener SAFe i tak dalej.
Chcesz wdrożyć SAFe w swojej organizacji? Sprawdź naszą ofertę szkoleniową SAFe.
Iulian Velea
Technical Project Manager | Certyfikowany konsultant programu SAFe (SPC4)