Rozwój oprogramowania w 2020 roku to szybko zmieniające się środowisko. Z dnia na dzień staje się coraz bardziej jasne, że jeśli nasze organizacje chcą przetrwać ten okres niepewności politycznej i gospodarczej, muszą być w stanie poruszać się z szybkością i zdolnością adaptacji. Ale jak kontrolować bezpieczeństwo przy prędkości? Jeśli Twoim celem jest przejście od cyklu dostarczania oprogramowania, który został zbudowany z dużą ilością barier i rzadkich wdrożeń, do bardziej nowoczesnej metodologii, która wspiera reaktywność poprzez częste wydania, aby dostarczać wartość swoim klientom tak szybko i bezpiecznie, jak to tylko możliwe, wtedy to, komu powierzasz odpowiedzialność za decyzje związane z zarządzaniem zmianami, ma duże znaczenie.

Tradycyjnie w wielu organizacjach decyzje te są podejmowane centralnie przez kierownika ds. zmian, który prowadzi okresowe spotkania komitetu doradczego ds. zmian (CAB). Sam CAB jest zbiorem przedstawicieli różnych funkcji wewnątrz i na zewnątrz korporacyjnego działu IT, których zadaniem jest przeglądanie proponowanych zmian i pomaganie kierownikowi ds. zmian w ocenie zmian, ustalaniu priorytetów i harmonogramu. Z założenia jest to grupa, która nie jest bezpośrednio zaangażowana w projektowanie lub wdrażanie proponowanej zmiany, dlatego proces przez nią prowadzony jest znany jako przegląd „zewnętrzny”.

Ale kto powinien być za to odpowiedzialny? Aby najlepiej wspierać zarówno szybkość i bezpieczeństwo, jak i wpływ na biznes, zespoły programistów i klienci powinni być odpowiedzialni za podejmowanie decyzji. Z technicznego punktu widzenia programiści mają lepsze pojęcie o tym, co znajduje się w wydaniu, czy istnieją współzależności i czy zostało ono przetestowane, niż jakikolwiek komitet doradczy ds. zmian. Z perspektywy biznesowej nadszedł czas, abyśmy zdali sobie sprawę, że to klient jest ostatecznym arbitrem tego, co zadziała, a co nie, a nie jakiś starszy menedżer, a już na pewno nie rada ds. zmian.

Zespół doradców ds. zmian może być wolniejszy, ale przynajmniej bezpieczniejszy, prawda?

Zespół doradców ds. zmian (i wiele z tego, co można znaleźć w ITIL) może wydawać się rozsądnym sposobem na zmniejszenie ryzyka i dodanie rygoru, szczególnie w wolno poruszających się, złożonych środowiskach. Jeśli masz tylko jeden strzał co 30 lub 90 dni, aby zmienić produkcję, utrzymywanie rzeczy poza wydaniami z bramkami jakości i zatwierdzeniami kierownictwa wygląda jak dobry sposób zarządzania ryzykiem. Nikt nie będzie dyskutował, że jest to wolniejszy proces (który może dodać tygodnie lub miesiące do czasu pomiędzy napisaniem kodu przez programistę a jego uruchomieniem), ale jest bezpieczniejszy, prawda?

Właściwie, nie. To nie jest.

Wieloletnie badania przeprowadzone w wielu różnych branżach i środowiskach wykazały, że posiadanie CAB lub podobnego procesu „zewnętrznego zatwierdzania” było gorsze niż brak procesu zatwierdzania w ogóle. Oto co główny autor dr Nicole Fosgren miał do powiedzenia na temat wyników:

Znaleźliśmy, że zewnętrzne zatwierdzenia były negatywnie skorelowane z czasem realizacji, częstotliwością wdrażania i czasem przywracania, a nie miały korelacji z odsetkiem niepowodzeń zmian. Krótko mówiąc, zatwierdzanie przez organ zewnętrzny (taki jak kierownik lub CAB) po prostu nie działa w celu zwiększenia stabilności systemów produkcyjnych, mierzonej czasem przywracania usług i wskaźnikiem awaryjności zmian. Z pewnością jednak spowalnia działanie. W rzeczywistości jest gorsze niż brak procesu zatwierdzania zmian w ogóle.

Co jest lepsze niż brak zarządzania zmianami w ogóle?

Dr Fosgren i jej zespół nie sugerują, abyście nie mieli żadnego procesu zatwierdzania, ale biorąc pod uwagę, jak źle CAB radzą sobie w prawdziwym świecie, powinniśmy przemyśleć, jaki rodzaj procesu faktycznie zapewni wam bezpieczeństwo.

Oto kolejny cytat z badania Accelerate:

Naszą rekomendacją opartą na tych wynikach jest użycie lekkiego procesu zatwierdzania zmian opartego na wzajemnej weryfikacji, takiej jak programowanie w parach lub wewnątrzzespołowy przegląd kodu, połączonego z potokiem wdrażania w celu wykrycia i odrzucenia złych zmian. Ten proces może być używany dla wszystkich rodzajów zmian, w tym kodu, infrastruktury i zmian baz danych.

Peer Code Reviews Combined with What Now?

Kiedy przeczytałem tę rekomendację w marcu 2018 roku, nie miałem problemu z wizualizacją pierwszej połowy: peer code reviews i cotygodniowe dema zespołu były już normami w BlazeMeter. Druga połowa? Nie tak bardzo! Byliśmy „nowoczesną” chmurą-natywną aplikacją SaaS, ale nigdy nie słyszałem o „rurociągu wdrożeniowym wykrywającym i odrzucającym złe zmiany”.

Aby zarządzać ryzykiem podczas wydań z powrotem wtedy, używaliśmy kombinacji niebieskich/zielonych wdrożeń i wydań kanarkowych. Platforma wykonywała „pchanie”, ale nie „wykrywanie” czy „odrzucanie” – to należało do naszych najlepszych i najbystrzejszych SRE, którzy ręcznie sprawdzali zdrowie dziesiątek rzeczy, zanim podnieśliśmy się do 100% użytkowników. Czytanie „wykrywaj i odrzucaj złe zmiany” wywoływało jedynie obraz czarnego pudełka na tablicy z napisem „tu dzieje się magia”. Wróciłem do studiów filmowych w college’u, gdzie dowiedziałem się, co znaczy „deus ex machina”.

Detect and Reject: Examples Are Out There If You Look

W ciągu dwóch lat wiele może się zmienić. Odkąd dołączyłem do Split jako CD Evangelist, widziałem Lukas Vermeer opisać, jak Booking.com rurociągu wdrażania może wykryć i przywrócić złą zmianę w ciągu jednej sekundy. Słuchałem, jak Sonali Sheel z Walmart Labs wyjaśnia, jak wykorzystują swoją platformę Expo, aby zatrzymać wdrożenie w połowie drogi, zanim wyrządzi ono szkody ich kluczowym wskaźnikom, coś, co nazywają Test to Launch.

Platforma Split Feature Delivery Platform została stworzona przez ludzi o podobnych wizjach nowoczesnego zarządzania zmianami, opartych na doświadczeniach z LinkedIn, Salesforce.com i Yahoo. Założyciele otrzymali porady od osób, które poradziły sobie ze złożonością, szybkością i skalą podobnych systemów w firmach Amazon i Microsoft.

Kiedy usłyszałem o Split i odkryłem przykłady, które komercjalizowali, skoczyłem na szansę, aby do nich dołączyć. Budowanie takiej platformy w domu było czymś, na co tylko kilku gigantów miało czas i zasoby, aby się zmierzyć. Jeśli ten sam rodzaj drobnoziarnistej ekspozycji i automatycznego wykrywania wpływu byłby dostępny jako SaaS, wtedy dostarczanie oprogramowania opartego na wpływie mogłoby być odblokowane dla każdego zespołu, a nie tylko startupów-jednorożców.

To niesamowite, ale nie zadziała tutaj

Zabawna rzecz zdarzała się raz za razem, kiedy podróżowałem na konferencje technologiczne, prowadząc rozmowy o wczesnych pionierach, którzy zbudowali te platformy w domu. Publiczność reagowała najpierw z zachwytem, a potem z rezygnacją. „To jest całkiem fajne, ale nie jesteśmy Booking.com, LinkedIn, lub Facebook. Nie możemy tego zrobić w naszym środowisku.”

W moich wysiłkach, aby być „vendor-neutralny” przez unikanie specyfiki wdrożenia Split, miałem praktycznie przerysowane, że niewyraźny obraz czarnego pudełka oznaczone „magia dzieje się tutaj”.

What If It Wasn’t So Hard?

Jeśli nigdy nie widziałeś platformy, która zapewnia drobnoziarnistą kontrolę ekspozycji i rygorystyczny zautomatyzowany mechanizm wykrywania i odrzucania złych zmian w twoim środowisku, nie można cię winić za myślenie, że to science fiction.

Okazuje się, że są tylko cztery główne problemy do rozwiązania:

1. Oddzielić deploy od release, więc kod może być pchany aż do produkcji, ale nie może być wykonywany, dopóki nie będzie gotowy. Ułatwia to prawdziwą ciągłą integrację, małe rozmiary partii, przyrostowy rozwój funkcji i rozgałęzianie przez abstrakcję, które są krytyczne dla ciągłego dostarczania, gdzie przepływ jest normą.
2. Selektywnie eksponuj nowy kod, zaczynając od małych wewnętrznych odbiorców i pracując na zewnątrz. Ułatwia to testowanie w produkcji, dogfooding, programy wczesnego dostępu oraz grupowanie zmian dla klientów niechętnych zmianom.
3. Pozyskiwanie danych o systemie i zachowaniu użytkowników oraz dostosowanie ich do danych o ekspozycji, wskazujących kto jest i nie jest w każdej kohorcie użytkowników. Celem jest, aby proces atrybucji (wyrównanie „Kto dostał co?”, z „Wtedy to się stało”) był automatyczny i ciągły.
4. Porównaj wzorce metryk pomiędzy tymi, którzy zostali włączeni i wykluczeni z każdej kohorty, aby zidentyfikować (i opcjonalnie zaalarmować) znaczące różnice. Być może widziałeś ten wzorzec wcześniej w kontekście „testów A/B”, które zazwyczaj śledzą wpływ zmian na metrykę konwersji, ale tutaj mówimy o szerokim śledzeniu wpływu całej pracy inżynierskiej i nieustannie czujnym obserwowaniu wpływu na wszystkie cenione przez organizację metryki, niezależnie od tego, czy wpływ na te metryki jest oczekiwany, czy nie.

Progresywne dostarczanie: An Easily Established Foundation

Oddzielenie wdrożenia od wydania i selektywne eksponowanie nowego kodu stają się znane jako progresywne dostarczanie, termin ukuty przez analityka RedMonk, Jamesa Governora. Wielu dostawców komercyjnych flag funkcji zapewnia te możliwości po wyjęciu z pudełka i pojawia się konsensus, że flagi funkcji dołączyły do listy narzędzi deweloperskich, które mają więcej sensu, aby kupić niż budować i utrzymywać w domu.

Feature flags są niezbędnym fundamentem do osiągnięcia przepływu, ale same w sobie nie przyspieszają wykrywania wpływu. Większość implementacji flag funkcji ułatwia przepływ, ale nie robi nic, aby wskazać, czy wszystko jest w porządku lub czy osiągasz znaczące wyniki.

Head’s Up: Data Scientists Don’t Scale

Ingesting systemu i zachowanie użytkownika i automatyczne dostosowanie go do narażonych kohort jest rzadkością wśród wszystkich, ale najbardziej wyrafinowanych systemów wewnętrznych. Większość zespołów próbujących tej praktyki wykonuje wiele ręcznych i doraźnych prac z zakresu data science. Ponieważ są one ograniczone przez zasoby ludzkie, a nie możliwości obliczeniowe, są zmuszone do wybierania i decydowania, kiedy i gdzie zwrócić uwagę.

Obciążenie poznawcze nie jest twoim przyjacielem, gdy dążysz do przepływu, więc projekt Splitu nie wymaga nawet od zespołów wybierania zdarzeń, które mają być powiązane z każdym rolloutem flagi funkcji; wszystkie pobrane zdarzenia, raz powiązane z metrykami organizacyjnymi, są stale przypisywane do włączonych i wyłączonych kohort każdego rolloutu, bez żadnej interwencji. Split ułatwia również pracę związaną z identyfikacją i pobieraniem danych o zdarzeniach dzięki integracji z Segment, Sentry, mParticle i Google Analytics.

Semper Fi for Continuous Delivery Pipelines

Porównanie wzorców metryk pomiędzy osobami włączonymi i niewłączonymi do każdej kohorty w rygorystyczny sposób, aby automatycznie określić znaczące różnice, jest jeszcze bardziej rzadkie w naturze niż atrybucja. To jest dokładnie ten problem, który rozwiązują moduły Monitor i Experimentation firmy Split. Monitor koncentruje się na identyfikacji i ostrzeganiu o wpływie na metryki w trakcie wdrażania (znane również jako „ograniczanie promienia rażenia incydentów”), podczas gdy Experimentation, podobnie jak testy A/B, stara się zapewnić ciągłe źródło bezstronnych danych, nieograniczone dostępnością analityka, aby wskazać, czy każda funkcja osiągnęła pożądany wpływ, czy nie.

Better Together: Peer Review, Progressive Delivery and Automated Sense-Making

Dlaczego dążymy do przepływu? Nie chodzi o wydajność. Chodzi o wyniki. Dążymy do płynności, aby móc powtarzać pętlę sprzężenia zwrotnego pomysł ->wdrożenie ->obserwacja z mniejszym tarciem i w krótszym czasie. Niezależnie od tego, czy nazwiemy to „rozwojem zorientowanym na wpływ” czy „rozwojem zorientowanym na klienta”, to podejście do szybszego poruszania się z większą (i szybszą) świadomością wyników wykracza daleko poza „rurociąg wdrożeniowy do wykrywania i odrzucania złych zmian”, który zespół DORA zalecił nam połączyć z praktykami wzajemnej weryfikacji. Tak, możemy automatycznie wykrywać i odrzucać złe zmiany, ale co ważniejsze, możemy zbudować powtarzalny proces triangulacji w kierunku znaczących wyników biznesowych.

Learn More About Achieving Change Management and Flow, Together, in Continuous Delivery

• Zobacz czterominutowe wideo na temat definicji Continuous Delivery, aby dowiedzieć się, dlaczego mały rozmiar partii jest krytyczny dla osiągnięcia spójnego przepływu.
• Pobierz wskazówki od wielu zespołów, które codziennie dostarczają produkty do produkcji w e-booku O’Reilly, Continuous Delivery in the Wild
• Obejrzyj szczegółowy film z Craigiem Sebenikiem (LinkedIn, Crunchbase, Matterport) na temat korzyści płynących z przejścia na rozwój oparty o trunk.

Szukasz więcej świetnych treści na temat osiągania znaczących wyników dzięki dostarczaniu funkcji w skali? Załóż zakładki na blogu Split, sprawdź nas na YouTube lub śledź nas na Twitterze @splitsoftware.