Inxhinieria e publikimeve mobile: dorëzim i besueshëm në çdo sprint

Publikimi mobil nuk kthehet mbrapa

Një deploy në web që shkon keq kthehet mbrapa brenda pak minutash. Publikimi mobil jo: sapo binari kalon shqyrtimin e store-it dhe përdoruesit përditësohen, ai kod ekzekutohet në pajisjet e tyre derisa secili të vendosë ta zëvendësojë — dhe një pjesë e konsiderueshme e bazës së instalimeve qëndron me versione të vjetra për muaj të tërë. Leva e shpërndarjes është në duart e dy store-ve dhe të miliona vendimeve individuale për përditësim, të cilat ju nuk i kontrolloni.

Pikërisht kjo asimetri e bën inxhinierinë e publikimeve mobile një disiplinë më vete. Ekipet që i trajtojnë publikimet e aplikacioneve si deploy-e web-i e kuptojnë ndryshimin gjatë publikimit të parë problematik. Zgjidhja nuk është të publikoni më rrallë — publikimet e rralla janë më të mëdha dhe më të rrezikshme. Zgjidhja është të inxhinierohet vetë procesi: trena publikimesh, feature flags, shpërndarje e shkallëzuar dhe monitorim i ndërtuar për një botë pa rollback.

Trena publikimesh, jo publikime heroike

Ndryshimi me efektin më të madh që mund të bëjë shumica e ekipeve mobile është kadenca fikse e publikimit. Çdo javë ose çdo dy javë, dega e publikimit pritet sipas kalendarit. Çfarë është bashkuar, testuar dhe mbrojtur me flag hipën në tren; gjithçka tjetër pret — dhe nisja e radhës nuk është kurrë më larg se një sprint. Vendos kalendari, jo negociata.

Kjo tingëllon burokratike, por është e kundërta: heq debatin për ta mbajtur publikimin edhe për një veçori, e mban çdo publikim mjaftueshëm të vogël për t'u arsyetuar dhe e mban makinerinë e publikimit të mprehtë.

• Dega e publikimit pritet automatikisht në një ditë fikse; stabilizohet dega, kurrë nuk ngrihet trunk-u
• Në degën e prerë futen me cherry-pick vetëm rregullime regresionesh — kurrë veçori të reja
• Treni i humbur i kushton një veçorie disa ditë, jo një tremujor — dhe pikërisht kjo e bën rregullin të zbatueshëm

Feature flags janë rollback-u i vërtetë

Meqë binari nuk mund të tërhiqet, vendimi i publikimit duhet ndarë nga shpërndarja. Çdo veçori thelbësore bashkohet e fikur, pas një flag-u që vlerësohet nga distanca. Dërgimi i kodit dhe ekspozimi i sjelljes bëhen dy akte të pavarura: treni e çon veçorinë në pajisje; flag-u vendos kur — dhe për kë — ajo ndizet.

Flags janë njëkohësisht i vetmi rollback që keni realisht. Një kill switch që çaktivizon një rrugë të rrezikshme kodi brenda sekondash vlen më shumë se çdo kërkesë për shqyrtim të përshpejtuar. Kjo funksionon vetëm me disiplinë: çdo flag ka pronar dhe afat skadimi, flags të vjetruara hiqen sepse secila e shumëfishon matricën e testimit, dhe klienti duhet të dështojë në mënyrë të sigurt — me vlera të ruajtura ose të parazgjedhura kur shërbimi i konfigurimit nuk arrihet.

Shpërndarje e shkallëzuar me kritere ndalimi të paracaktuara

Të dy store-t kryesorë mbështesin shpërndarjen me faza; përdoreni me qëllim, jo si kuti për t'u shënuar. Një rampë e provuar: 1 përqind ditën e parë, pastaj 5, 25, 50, 100 — duke ecur përpara vetëm sa kohë që shifrat qëndrojnë. Kriteret e ndalimit shkruhen para publikimit, nuk improvizohen gjatë tij: sesione pa crash mbi 99.8 përqind dhe jo më keq se versioni paraardhës, asnjë sinjaturë e re crash-i mbi pragun e rënë dakord, metrikat kryesore të funnel-it brenda luhatjes normale.

Kjo politikë vlen aq sa telemetria pas saj. Raportimi i crash-eve i takon build-it të parë të brendshëm, me simbolikim që stack trace-t të lexohen qartë, me alarme për sinjatura të reja dhe shpejtësinë e përhapjes së tyre, dhe me drejtim që ia vë çdo crash përpara ekipit që e zotëron kodin. Një pik i kapur në 5 përqind është shënim në ditarin e publikimit; i njëjti pik në 100 përqind është incident.

Automatizoni rrugën nëpër store

Shqyrtimi i store-it është një radhë që nuk e kontrolloni dot, prandaj gjithçka në anën tuaj të saj duhet të mos kërkojë duar njeriu. Nënshkrimi dhe provisioning jetojnë në CI, numrat e versionit dhe të build-it derivohen automatikisht, shënimet e publikimit dhe metadata gjenerohen nga repository dhe vetë dorëzimi kalon përmes API-ve të store-ve. Prova e vërtetë e pipeline-it është stërvitja e hotfix-it: nga një rregullim njërreshtësh deri te një build i dorëzuar e gati për shqyrtim duhen minuta punë njeriu, jo një pasdite ceremonish.

• Kontrolle para dorëzimit që i kapin refuzimet herët: deklaratat e privatësisë, tekstet e lejeve, nivelet e synuara të API-ve, buxhetet e madhësisë së binarit
• Shpërndarje e automatizuar e çdo bashkimi në një kanal të brendshëm, që ekipi të jetojë sot me publikimin e së nesërmes
• Kërkesat për shqyrtim të përshpejtuar ruhen për urgjenca të vërteta — ato pushojnë së funksionuari sapo bëhen rutinë

Si duket praktika e shëndetshme

Sinjalet e një praktike të shëndetshme publikimi janë të thjeshta dhe pa bujë. Publikimet dalin sipas kalendarit, pavarësisht gatishmërisë së ndonjë veçorie të veçantë. Sesionet pa crash qëndrojnë mbi objektiv gjatë gjithë shpërndarjes, publikim pas publikimi. Një rregullim i bashkuar arrin te përdoruesit brenda orësh, dhe pjesa më e madhe e instalimeve qëndron në njërin nga dy versionet më të fundit — me përditësimin e detyruar rezervë për minimume sigurie, kurrë si patericë.

Inxhinieria e publikimeve është një nga disiplinat që Vendenis sjell në punën me produktet mobile, krahas praktikave të arkitekturës dhe të cilësisë që kërkon pjesa tjetër e ciklit jetësor. Qëllimi thuhet lehtë dhe arrihet me vështirësi: një publikim aq rutinë sa dorëzimi në çdo sprint të jetë zakon, jo ambicie.