A szoftverfejlesztés 2020-ban gyorsan változó környezet. Napról napra világosabbá válik, hogy ha szervezeteink túl akarják élni ezt a politikai és gazdasági bizonytalansággal teli időszakot, akkor képesnek kell lenniük a gyorsaságra és az alkalmazkodóképességre. De hogyan ellenőrizhetjük a biztonságot a sebesség mellett? Ha az a cél, hogy a sok védőkorlátra és ritkán végrehajtott telepítésekre épülő szoftvertovábbítási ciklusról egy modernebb módszertanra térjen át, amely a gyakori kiadásokon keresztül támogatja a reagálóképességet, hogy a lehető leggyorsabban és legbiztonságosabban áramoljon érték az ügyfelekhez, akkor nagyon is számít, hogy kit bíz meg a változáskezelési döntésekkel.

Hagyományosan sok szervezetben ezeket a döntéseket központilag egy változáskezelő hozza meg, aki rendszeres időközönként változással foglalkozó tanácsadó testület (CAB) üléseket tart. Maga a CAB a vállalati IT-n belüli és kívüli különböző funkciók képviselőinek gyűjteménye, akiknek feladata a javasolt változtatások felülvizsgálata és a változásmenedzser segítése a változások értékelésében, rangsorolásában és ütemezésében. Ez a csoport eleve nem vesz részt közvetlenül a javasolt változtatás megtervezésében vagy végrehajtásában, ezért az általuk végzett folyamatot “külső” felülvizsgálatnak nevezik.

De ki legyen a felelős? Annak érdekében, hogy mind a sebességet és a biztonságot, mind az üzleti hatást a legjobban támogassa, azt szeretné, ha a fejlesztőcsapatok és az ügyfelek irányítanák a döntéshozatalt. Technikai szempontból a fejlesztői jobban tudják, hogy mi van egy kiadásban, hogy léteznek-e függőségek, és hogy tesztelték-e, mint bármelyik változtatási tanácsadó testület. Üzleti szempontból itt az ideje felismerni, hogy az ügyfél a végső döntőbírája annak, hogy mi fog működni és mi nem, nem pedig egy felsővezető, és főleg nem a változtatási tanácsadó testület.

A változtatási tanácsadó testület lehet, hogy lassabb, de legalább biztonságosabb, igaz?

A változtatási tanácsadó testület (és sok minden, amit az ITIL-ben talál) ésszerű módszernek tűnhet a kockázat csökkentésére és a szigor növelésére, különösen a lassan változó, összetett környezetekben. Ha csak 30 vagy 90 naponta egyszer van lehetőséged a termelés megváltoztatására, akkor a dolgok minőségkapukkal és vezetői jóváhagyásokkal való távoltartása a kiadásoktól jó módszernek tűnik a kockázatkezelésre. Senki sem vitatja, hogy ez egy lassabb folyamat (ami hetekkel vagy hónapokkal növelheti a fejlesztő által írt kód és az éles üzembe helyezés közötti időt), de biztonságosabb, nem igaz?

Valójában nem. Nem az.

Egy többéves, sokféle iparágban és környezetben végzett tanulmány szerint a CAB vagy hasonló “külső jóváhagyási” folyamat rosszabbul teljesített, mintha egyáltalán nem volt jóváhagyási folyamat. Itt van, amit a vezető szerző, Dr. Nicole Fosgren mondott az eredményekről:

Megállapítottuk, hogy a külső jóváhagyások negatívan korreláltak az átfutási idővel, a bevezetési gyakorisággal és a visszaállítási idővel, és nem álltak összefüggésben a változások meghiúsulási arányával. Röviden, a külső szerv (például egy vezető vagy a CAB) általi jóváhagyás egyszerűen nem növeli a termelési rendszerek stabilitását, a szolgáltatás helyreállításának idejével és a változtatási hibaaránnyal mérve. Az azonban biztos, hogy lelassítja a dolgokat. Valójában rosszabb, mintha egyáltalán nem lenne változás-jóváhagyási folyamat.

Mi jobb annál, mintha egyáltalán nem lenne változáskezelés?

Dr. Fosgren és csapata valójában nem azt javasolja, hogy ne legyen jóváhagyási folyamat, de tekintve, hogy a CAB-ok milyen rosszul teljesítenek a való világban, újra kellene gondolnunk, hogy milyen folyamat valóban biztonságot nyújt.

Itt egy másik idézet az Accelerate tanulmányból:

Az ezeken az eredményeken alapuló ajánlásunk az, hogy egy könnyített, szakértői értékelésen alapuló változtatás-jóváhagyási folyamatot használjunk, például páros programozást vagy intrateam kódellenőrzést, kombinálva egy telepítési csővezetékkel a rossz változtatások felismerésére és elutasítására. Ez a folyamat mindenféle változtatásra alkalmazható, beleértve a kód, az infrastruktúra és az adatbázis változtatásait is.”

Peer code reviews kombinálva What Now?

Amikor 2018 márciusában olvastam ezt az ajánlást, nem volt gondom az első felét elképzelni: a peer code reviews és a heti csapatdemó már a BlazeMeternél is a normák közé tartozott. A második fele? Nem annyira! Mi egy “modern” felhő-natív SaaS-alkalmazás voltunk, de még sosem hallottam arról, hogy “egy telepítési csővezeték felismeri és elutasítja a rossz módosításokat”.

Az akkori kiadások során a kockázatok kezelésére a kék/zöld telepítések és a kanári kiadások kombinációját használtuk. A platform végezte a “tologatást”, de nem a “detektálást” vagy “visszautasítást” – ez a legjobb és legokosabb SRE-inkre hárult, akik kézzel ellenőrizték több tucat dolog állapotát, mielőtt 100%-os felhasználói szintre emeltük volna. A “rossz változások észlelése és visszautasítása” elolvasása csak egy fekete doboz képét hozta felénk egy táblán azzal a felirattal, hogy “itt történik a varázslat”. Visszatekintés a főiskolai filmtudományi tanulmányokra, ahol megtanultam, mit jelent a “deus ex machina”.

Felismerés és visszautasítás:

Két év alatt sok minden változhat. Mióta CD Evangelistaként csatlakoztam a Splithez, végignéztem, ahogy Lukas Vermeer leírja, hogyan képes a Booking.com telepítési csővezetéke egyetlen másodpercen belül felismerni és visszafordítani egy rossz módosítást. Hallgattam, ahogy Sonali Sheel a Walmart Labs-től elmagyarázta, hogyan használják az Expo platformjukat arra, hogy félúton megállítsák a bevezetést, mielőtt az kárt okozna a legfontosabb mérőszámaikban, amit ők Test to Launchnak hívnak.

A Split Feature Delivery Platformot olyan emberek hozták létre, akiknek hasonló elképzeléseik vannak a modern változáskezelésről a LinkedIn-nél, a Salesforce.com-nál és a Yahoo-nál szerzett tapasztalataik alapján. Az alapítók olyan emberektől kaptak tanácsot, akik az Amazon és a Microsoft hasonló rendszereinek összetettségével, sebességével és méretével foglalkoztak.

Amikor hallottam a Splitről, és felfedeztem az általuk kereskedelmi forgalomba hozott példákat, megragadtam a lehetőséget, hogy csatlakozzam hozzájuk. Egy ilyen platform házon belüli felépítése olyasmi volt, amire csak néhány óriásnak volt ideje és erőforrása. Ha ugyanez a fajta finom szemcseméretű kitettség és automatikus hatásérzékelés SaaS-ként lenne elérhető, akkor a hatásvezérelt szoftverszállítás minden csapat számára elérhetővé válna, nem csak az egyszarvú startupok számára.

Ez csodálatos, de itt nem fog működni

Egy vicces dolog történt újra és újra, amikor technológiai konferenciákra utaztam, és előadásokat tartottam a korai úttörőkről, akik házon belül építették ezeket a platformokat. A hallgatóság először csodálkozva, majd lemondóan reagált. “Ez nagyon király, de mi nem vagyunk Booking.com, LinkedIn vagy Facebook. A mi környezetünkben ezt nem tudjuk megtenni.”

Azzal az igyekezetemmel, hogy a Split megvalósításának sajátosságait elkerülve “gyártósemleges” legyek, gyakorlatilag újrarajzoltam azt a homályos képet egy “itt történik a varázslat” feliratú fekete dobozról.

Mi lenne, ha nem lenne olyan nehéz?

Ha még sosem látott olyan platformot, amely a kitettség finomszemcsés ellenőrzését és egy szigorú automatizált mechanizmust biztosít a környezetében bekövetkező rossz változások észlelésére és elutasítására, nem hibáztatható, ha azt hiszi, hogy ez sci-fi.

Kiderül, hogy itt mindössze négy fő problémát kell megoldani:

1. A telepítés és a kiadás szétválasztása, így a kódot egészen a termelésig lehet tolni, de a végrehajtás megakadályozható, amíg készen nem áll. Ez megkönnyíti a valódi folyamatos integrációt, a kis tételméreteket, az inkrementális funkciófejlesztést és az absztrakció általi elágazást, amelyek mind kritikusak a folyamatos szállítás megvalósításához, ahol a flow a norma.
2. Szelektíven tegyük közzé az új kódot, kezdve a kis belső közönséggel, majd kifelé haladva. Ez megkönnyíti a termelésben történő tesztelést, a dogfoodingot, a korai hozzáférési programokat és a változtatásokkal szemben ellenálló ügyfelek számára a változtatások kötegelését.
3. A rendszer és a felhasználók viselkedési adatainak felvétele és összehangolása a kitettségi adatokkal, amelyek jelzik, hogy ki van az egyes felhasználói kohorszokban és ki nem. A cél az, hogy a hozzárendelési folyamat (a “Ki mit kapott?” és az “Akkor ez történt” összehangolása) automatikus és folyamatos legyen.
4. Hasonlítsa össze az egyes kohorszokba bevont és onnan kizárt személyek mérőszámainak mintáit a jelentős különbségek azonosítása (és opcionálisan figyelmeztetés) érdekében. Ezt a mintát már korábban is láthatta az “A/B tesztelés” kontextusában, amely jellemzően a változásoknak egy konverziós mérőszámra gyakorolt hatását követi nyomon, de itt az összes mérnöki munka hatásának széles körű nyomon követéséről van szó, és folyamatosan figyelni kell a szervezet által értékelt összes mérőszámra gyakorolt hatásokat, függetlenül attól, hogy a mérőszámokra gyakorolt hatás várható-e vagy sem.

Progresszív szállítás: A RedMonk elemzője, James Governor által megalkotott kifejezés, a progresszív szállítás néven vált ismertté. Több kereskedelmi funkciózászló-gyártó kínálja ezeket a képességeket, és konszenzus van kialakulóban arról, hogy a funkciózászlók csatlakoztak azon fejlesztői eszközök listájához, amelyeket érdemesebb megvásárolni, mint házon belül létrehozni és karbantartani.

A feature flagek nélkülözhetetlen alapot jelentenek a flow eléréséhez, de önmagukban nem gyorsítják fel a hatások észlelését. A legtöbb feature flag implementáció megkönnyíti az áramlást, de semmit sem tesznek annak jelzésére, hogy minden rendben van-e, vagy hogy értelmes eredményeket érünk-e el.

Figyelem: Az adattudósok nem skálázódnak

A rendszer és a felhasználók viselkedésének felvétele és automatikus összehangolása a kitett kohorszokkal ritka a legfejlettebb házon belüli rendszereket kivéve. Az ezzel a gyakorlattal próbálkozó legtöbb csapat rengeteg manuális és ad-hoc adattudományos munkát végez. Mivel inkább az emberi erőforrások, mint a számítási kapacitás korlátozza őket, kénytelenek megválogatni, hogy mikor és hova fordítsanak figyelmet.

A kognitív terhelés nem a barátod, ha az áramlásra törekszel, ezért a Split tervezése még azt sem követeli meg a csapatoktól, hogy kiválasszák, mely eseményeket társítsák az egyes funkciózászlók bevezetéséhez; minden beolvasott esemény, miután szervezeti mérőszámokhoz kötötték, minden egyes bevezetés be- és kikapcsolt kohorszához folyamatosan, minden beavatkozás nélkül hozzárendelődik. A Split a Segment, a Sentry, az mParticle és a Google Analytics integrációi révén megkönnyíti az eseményadatok azonosításának és bevitelének munkáját is.

Semper Fi for Continuous Delivery Pipelines

A metrikák mintázatainak szigorú módon történő összehasonlítása az egyes kohorszokba felvettek és nem felvettek között a jelentős különbségek automatikus megállapítása érdekében még a vadonban is ritkább, mint az attribúció. A Split Monitor és Experimentation moduljai pontosan ezt a problémát oldják meg. A Monitor a mérőszámokra gyakorolt hatások azonosítására és riasztására összpontosít a bevezetés során (más néven “az incidensek robbanási sugarának korlátozására”), míg a Kísérletezés az A/B teszteléshez hasonlóan arra törekszik, hogy egy folyamatos, elfogulatlan adatforrást biztosítson, amelyet nem korlátoz az elemző rendelkezésre állása, hogy jelezze, az egyes funkciók elérték-e a kívánt hatást vagy sem.

Better Together: Peer Review, progresszív szállítás és automatizált értelmezés

Miért törekszünk az áramlásra? Nem a teljesítményről van szó. Hanem az eredményekről. Azért törekszünk az áramlásra, hogy az ötlet -> megvalósítás -> megfigyelés visszacsatolási körét kevesebb súrlódással, rövidebb idő alatt iterálhassuk. Akár “hatásvezérelt fejlesztésnek”, akár “ügyfélvezérelt fejlesztésnek” nevezzük, ez a megközelítés, hogy gyorsabban haladjunk az eredmények nagyobb (és gyorsabb) tudatosításával, jóval túlmutat a “rossz változtatások felismerésére és elutasítására szolgáló telepítési csővezetéken”, amelyet a DORA-csapat a szakértői értékelés gyakorlatával való kombinálásra ajánlott. Igen, automatikusan felismerhetjük és elutasíthatjuk a rossz változtatásokat, de ami ennél is fontosabb, kiépíthetünk egy megismételhető folyamatot az értelmes üzleti eredmények felé vezető triangulációhoz.”

Tudjon meg többet a változáskezelés és az áramlás együttes eléréséről a folyamatos szállításban

• Nézzen meg egy négyperces videót a folyamatos szállítás definíciójáról, hogy megtudja, miért kritikus a kis tételméret a következetes áramlás eléréséhez.
• Vegyél át tippeket több olyan csapattól, akik naponta szállítanak a termelésbe az O’Reilly e-bookjában, a Continuous Delivery in the Wild-ban
• Nézz meg egy mélyreható videót Craig Sebenikkel (LinkedIn, Crunchbase, Matterport) a törzsalapú fejlesztésre való áttérés előnyeiről.

Még több nagyszerű tartalmat keresel a funkciók méretarányos szállításával elérhető értelmes eredményekről? Tegye könyvjelzőbe a Split blogot, nézzen meg minket a YouTube-on, vagy kövessen minket a Twitteren @splitsoftware.