Inżynieria wydań mobilnych: niezawodne dostarczanie w każdym sprincie

Wydania mobilnego nie da się wycofać

Nieudany deployment webowy cofa się w kilka minut. Wydanie mobilne — nie: gdy binarka przejdzie recenzję sklepu, a użytkownicy zaktualizują aplikację, ten kod działa na ich urządzeniach, dopóki sami nie zdecydują się go wymienić — a znacząca część każdej bazy instalacji pozostaje na starych wersjach miesiącami. Dźwignia wdrożenia leży po stronie dwóch sklepów i milionów decyzji o aktualizacji, na które nie mają Państwo wpływu.

Ta asymetria czyni z inżynierii wydań mobilnych osobną dyscyplinę. Zespoły, które wypuszczają aplikacje jak deploye webowe, poznają różnicę przy pierwszym nieudanym wydaniu. Odpowiedzią nie jest wydawanie rzadziej — rzadkie wydania są większe i bardziej ryzykowne. Odpowiedzią jest zaprojektowanie samego procesu: release trains, feature flagi, stopniowe rollouty i monitoring zbudowany dla świata bez rollbacku.

Release trains zamiast wydań heroicznych

Zmianą o największej dźwigni dla większości zespołów mobilnych jest stały rytm wydań. Co tydzień lub co dwa tygodnie gałąź wydania jest odcinana zgodnie z harmonogramem. Wszystko, co zmergowane, przetestowane i schowane za flagą, wsiada do pociągu; reszta czeka — a następny odjazd nigdy nie jest dalej niż o jeden sprint. Decyduje kalendarz, nie negocjacje.

Brzmi to biurokratycznie, a jest dokładnie odwrotnie: kończy spory o wstrzymanie wydania dla jeszcze jednej funkcji, utrzymuje każde wydanie na tyle małe, by dało się nad nim zapanować, i utrzymuje maszynerię wydań w dobrej formie.

• Gałąź wydania odcinana automatycznie w stały dzień; stabilizuje się gałąź, nigdy nie zamraża trunka
• Na odciętą gałąź trafiają przez cherry-pick wyłącznie poprawki regresji — nigdy funkcje
• Spóźnienie na pociąg kosztuje funkcję kilka dni, a nie kwartał — i właśnie to czyni regułę egzekwowalną

Feature flagi to prawdziwy rollback

Skoro binarki nie da się odwołać, decyzję o wydaniu trzeba oddzielić od wdrożenia. Każda istotna funkcja jest mergowana na ciemno, za flagą ocenianą zdalnie. Dostarczenie kodu i udostępnienie zachowania stają się dwoma niezależnymi aktami: pociąg wiezie funkcję na urządzenia; flaga decyduje, kiedy — i dla kogo — zostanie włączona.

Flagi to zarazem jedyny rollback, jakim naprawdę Państwo dysponują. Kill switch, który w kilka sekund wyłącza ryzykowną ścieżkę kodu, jest wart więcej niż jakikolwiek wniosek o przyspieszoną recenzję. To działa tylko przy dyscyplinie: każda flaga ma właściciela i datę wygaśnięcia, przestarzałe flagi są usuwane, bo każda mnoży macierz testów, a klient musi bezpiecznie przechodzić na wartości z cache lub domyślne, gdy usługa konfiguracji jest niedostępna.

Stopniowe rollouty z kryteriami zatrzymania ustalonymi z góry

Oba główne sklepy wspierają dystrybucję etapami; należy z niej korzystać świadomie, a nie jak z pola do odhaczenia. Sprawdzona rampa: 1 procent pierwszego dnia, potem 5, 25, 50, 100 — z przechodzeniem dalej tylko dopóty, dopóki liczby się trzymają. Kryteria zatrzymania spisuje się przed wydaniem, a nie improwizuje w jego trakcie: sesje bez crashy powyżej 99,8 procent i nie gorzej niż w poprzedniej wersji, żadna nowa sygnatura crasha powyżej uzgodnionego progu, kluczowe metryki lejka w granicach normalnej wariancji.

Ta polityka jest warta tyle, ile stojąca za nią telemetria. Raportowanie crashy należy do pierwszego wewnętrznego builda — z symbolikacją, dzięki której stack trace'y czyta się czysto, alertami na nowe sygnatury i tempo ich narastania oraz routingiem, który stawia każdy crash przed zespołem odpowiedzialnym za kod. Skok wychwycony przy 5 procentach to notatka w dzienniku wydania; ten sam skok przy 100 procentach to incydent.

Automatyzacja drogi przez sklep

Recenzja w sklepie to kolejka, na którą nie mają Państwo wpływu, więc wszystko po Państwa stronie powinno obywać się bez ludzkich rąk. Podpisywanie i provisioning żyją w CI, numery wersji i buildów są wyprowadzane automatycznie, release notes i metadane generowane z repozytorium, a zgłoszenie przechodzi przez API sklepów. Miarą pipeline'u jest ćwiczenie z hotfixa: jednolinijkowa poprawka powinna stać się zgłoszonym, gotowym do recenzji buildem w kilka minut ludzkiej pracy, a nie w popołudnie ceremonii.

• Kontrole przed zgłoszeniem, które wcześnie wychwytują odrzucenia: deklaracje prywatności, teksty uprawnień, docelowe poziomy API, budżety rozmiaru binarki
• Automatyczna dystrybucja każdego merge'a na wewnętrzny kanał, aby zespół żył już dziś jutrzejszym wydaniem
• Wnioski o przyspieszoną recenzję zarezerwowane dla prawdziwych awarii — przestają działać, gdy stają się rutyną

Jak wygląda zdrowa praktyka

Sygnały zdrowej praktyki wydań są mało efektowne. Wydania wychodzą zgodnie z kalendarzem, niezależnie od gotowości pojedynczej funkcji. Sesje bez crashy utrzymują się powyżej celu przez cały rollout, wydanie po wydaniu. Zmergowana poprawka dociera do użytkowników w ciągu godzin, a większość instalacji działa na jednej z dwóch najnowszych wersji — z wymuszoną aktualizacją zarezerwowaną dla minimów bezpieczeństwa, nigdy jako protezą.

Inżynieria wydań to jedna z dyscyplin, które Vendenis wnosi do pracy nad produktami mobilnymi, obok praktyk architektury i jakości, których wymaga reszta cyklu życia. Cel łatwo wypowiedzieć i trudno osiągnąć: wydanie na tyle rutynowe, że publikacja w każdym sprincie jest nawykiem, a nie ambicją.