Ohjelmistokehitys vuonna 2020 on nopeasti muuttuva ympäristö. Päivä päivältä käy selvemmäksi, että jos organisaatiomme haluavat selvitä tästä poliittisen ja taloudellisen epävarmuuden ajasta, niiden on pystyttävä liikkumaan nopeasti ja sopeutumiskykyisesti. Mutta miten nopeuden turvallisuutta valvotaan? Jos tavoitteenasi on siirtyä ohjelmistotoimitussyklistä, jossa on paljon suojakaiteita ja harvoin tapahtuvia käyttöönottoja, nykyaikaisempaan menetelmään, joka tukee reagointikykyä tiheiden julkaisujen avulla, jotta asiakkaillesi voidaan tuottaa arvoa mahdollisimman nopeasti ja turvallisesti, sillä, kuka vastaa muutoksenhallintapäätöksistä, on paljon väliä.

Traditionaalisesti monessa organisaatiossa nämä päätökset tekee keskitetysti muutospäällikkö (change manager), joka pitää määräajoin muutosten neuvottelukunnan (change advisory board, CAB) kokouksia. Itse neuvoa-antava neuvoa-antava toimikunta on kokoelma eri toimintojen edustajia yrityksen IT:n sisältä ja ulkopuolelta, ja sen tehtävänä on tarkastella ehdotettuja muutoksia ja avustaa muutosjohtajaa muutosten arvioinnissa, priorisoinnissa ja aikatauluttamisessa. Kyseessä on ryhmä, joka ei lähtökohtaisesti osallistu suoraan ehdotetun muutoksen suunnitteluun tai toteuttamiseen, minkä vuoksi sen suorittamaa prosessia kutsutaan ”ulkoiseksi” tarkasteluksi.

Mutta, kenen pitäisi olla vastuussa? Jotta voit parhaiten tukea sekä nopeutta ja turvallisuutta että liiketoimintavaikutuksia, haluat, että kehitystiimisi ja asiakkaasi ohjaavat päätöksentekoa. Teknisestä näkökulmasta katsottuna kehittäjilläsi on parempi käsitys siitä, mitä julkaisussa on, onko riippuvuuksia olemassa ja onko se testattu, kuin millään muutosneuvottelukunnalla. Liiketoiminnan näkökulmasta katsottuna on aika ymmärtää, että asiakas ratkaisee lopullisesti, mikä toimii ja mikä ei, ei joku ylempi johtaja eikä varsinkaan muutosneuvottelukunta.

Muutosneuvottelukunta voi olla hitaampi, mutta ainakin se on turvallisempi, eikö niin?

Muutosneuvottelukunta (ja suuri osa siitä, mitä ITIL:stä löytyy) saattaa vaikuttaa järkeviltä tavoilta vähentää riskejä ja lisätä tiukkuutta erityisesti hitaasti etenevissä, monimutkaisissa ympäristöissä. Jos sinulla on vain yksi tilaisuus 30 tai 90 päivän välein muuttaa tuotantoa, asioiden pitäminen pois julkaisuista laatuporteilla ja johdon hyväksynnöillä näyttää hyvältä tavalta hallita riskejä. Kukaan ei väitä, että prosessi on hitaampi (mikä voi lisätä viikkoja tai kuukausia aikaan, joka kuluu siitä, kun kehittäjä kirjoittaa koodia ja se otetaan käyttöön), mutta se on turvallisempi, eikö niin?

Ei oikeastaan. Ei ole.

Monivuotisessa tutkimuksessa, joka koski useita eri toimialoja ja ympäristöjä, todettiin, että CAB:n tai vastaavanlaisen ”ulkoisen hyväksymisprosessin” käyttäminen toimi huonommin kuin se, ettei hyväksymisprosessia ollut lainkaan. Tohtori Nicole Fosgren, tutkimuksen pääkirjoittaja, kommentoi tuloksia seuraavasti:

Havaitsimme, että ulkoiset hyväksynnät korreloivat negatiivisesti läpimenoajan, käyttöönottotiheyden ja palautusajan kanssa, eikä niillä ollut korrelaatiota muutosten epäonnistumisasteen kanssa. Lyhyesti sanottuna ulkoisen elimen (kuten johtajan tai CAB:n) hyväksyntä ei yksinkertaisesti tehoa tuotantojärjestelmien vakauden lisäämiseen, jota mitataan palvelun palauttamiseen kuluvalla ajalla ja muutosten epäonnistumisasteella. Se kuitenkin varmasti hidastaa asioita. Se on itse asiassa pahempi kuin se, ettei muutosten hyväksymisprosessia ole lainkaan.

Mikä on parempi kuin ei muutostenhallintaa lainkaan?

Tohtori Fosgren ja hänen tiiminsä eivät varsinaisesti ehdota, että hyväksymisprosessia ei olisi lainkaan, mutta kun otetaan huomioon, miten huonosti CAB:t toimivat todellisessa maailmassa, meidän pitäisi miettiä uudestaan, millainen prosessi oikeasti pitää sinut turvassa.

Tässä on toinen lainaus Accelerate-tutkimuksesta:

Suosituksemme näiden tulosten perusteella on käyttää kevyttä muutosten hyväksymisprosessia, joka perustuu vertaisarviointiin, kuten parityöskentelyyn tai tiimin sisäiseen koodin tarkasteluun, yhdistettynä käyttöönottoputkeen huonojen muutosten havaitsemiseksi ja hylkäämiseksi. Tätä prosessia voidaan käyttää kaikenlaisiin muutoksiin, kuten koodi-, infrastruktuuri- ja tietokantamuutoksiin.”

Vertaiskoodikatselmukset yhdistettynä mihinkä nyt?

Kun luin tuon suosituksen maaliskuussa 2018, minulla ei ollut mitään ongelmaa havainnollistaa ensimmäistä puoliskoa: vertaiskoodikatselmukset ja viikoittaiset tiimitason demonstraatiot olivat jo BlazeMeterin normi. Toinen puolikas? Ei niinkään! Olimme ”moderni” pilvipohjainen SaaS-sovellus, mutta en ollut koskaan kuullutkaan ”käyttöönottoputkesta, joka havaitsee ja hylkää huonot muutokset”.

Riskien hallitsemiseksi julkaisujen aikana käytimme tuolloin sinivihreiden käyttöönottojen ja canary-julkaisujen yhdistelmää. Alusta teki ”työntämisen”, mutta ei ”havaitsemista” tai ”hylkäämistä” – se oli meidän parhaiden ja älykkäimpien SRE:iemme vastuulla, jotka tarkistivat kymmenien asioiden kunnon manuaalisesti ennen kuin otimme käyttöön 100 % käyttäjiä. ”Huonojen muutosten havaitseminen ja hylkääminen” toi esiin vain kuvan mustasta laatikosta valkotaululla, jossa luki ”magic happens here”. Palautin mieleeni yliopistossa suoritetut elokuvaopinnot, joissa opin, mitä ”deus ex machina” tarkoittaa.

Havaitse ja hylkää:

Paljon voi muuttua kahdessa vuodessa. Siitä lähtien, kun tulin Splitin CD-evankelistaksi, olen seurannut Lukas Vermeerin kuvausta siitä, miten Booking.comin käyttöönottoputki voi havaita ja peruuttaa huonon muutoksen yhden sekunnin sisällä. Olen kuunnellut Sonali Sheelin Walmart Labsista selittävän, miten he käyttävät Expo-alustaansa pysäyttääkseen käyttöönoton kesken ennen kuin se vahingoittaa keskeisiä tunnuslukujaan, mitä he kutsuvat nimellä Test to Launch.

Splitin Feature Delivery Platform -alustan ovat luoneet ihmiset, joilla on samanlainen näkemys nykyaikaisesta muutosjohtamisesta LinkedInissä, Salesforce.comissa ja Yahoossa hankittujen kokemusten perusteella. Perustajat saivat neuvoja ihmisiltä, jotka olivat käsitelleet vastaavien järjestelmien monimutkaisuutta, nopeutta ja laajuutta Amazonilla ja Microsoftilla.

Kun kuulin Splitistä ja huomasin esimerkit, joita he olivat kaupallistamassa, tartuin tilaisuuteen liittyä heihin. Tällaisen alustan rakentaminen talon sisällä oli jotain, mihin vain muutamalla jättiläisellä oli aikaa ja resursseja. Jos samanlainen hienojakoinen altistuminen ja automatisoitu vaikutusten havaitseminen olisi saatavilla SaaS-palveluna, vaikutuksiin perustuva ohjelmistotoimitus voitaisiin avata jokaiselle tiimille, ei vain yksisarvisille startup-yrityksille.

Tämä on hämmästyttävää, mutta se ei toimi täällä

Hauska juttu tapahtui kerta toisensa jälkeen, kun matkustin teknologiakonferensseihin ja pidin puheita varhaisista edelläkävijöistä, jotka olivat rakentaneet tällaiset alustat talon sisällä. Yleisö reagoi ensin hämmästyneenä ja sitten tyynesti. ”Aika hienoa, mutta me emme ole Booking.com, LinkedIn tai Facebook. Emme voi tehdä sitä meidän ympäristössämme.”

Pyrkiessäni olemaan ”toimittajaneutraali” välttelemällä Splitin toteutuksen yksityiskohtia olin käytännössä piirtänyt uudelleen tuon sumean kuvan mustasta laatikosta, jossa luki ”magic happens here”.

Mitä jos se ei olisi niin vaikeaa?

Jos et ole koskaan nähnyt alustaa, joka tarjoaa hienojakoista altistumisen hallintaa ja tiukan automaattisen mekanismin ympäristön huonojen muutosten havaitsemiseen ja hylkäämiseen, sinua ei voi syyttää siitä, että luulet sen olevan scifiä.

Kävi ilmi, että tässä on vain neljä pääongelmaa ratkaistavana:

1. Kytke käyttöönotto irti julkaisusta, jotta koodi voidaan työntää aina tuotantoon asti, mutta estää sen suorittaminen, kunnes se on valmis. Tämä helpottaa todellista jatkuvaa integrointia, pieniä eräkokoja, inkrementaalista ominaisuuksien kehittämistä ja haarautumista abstraktion avulla, jotka kaikki ovat kriittisiä jatkuvan toimituksen toteuttamiselle, jossa virtaus on normi.
2. Valikoivasti paljastaa uutta koodia, aloittaen pienestä sisäisestä yleisöstä ja edeten ulospäin. Tämä helpottaa testausta tuotannossa, dogfoodingia, early access -ohjelmia ja muutosten panostamista muutoksiin kielteisesti suhtautuville asiakkaille.
3. Järjestelmä- ja käyttäjäkäyttäytymistä koskevien tietojen kerääminen ja yhteensovittaminen altistumistietojen kanssa, joista käy ilmi, ketkä kuuluvat kuhunkin käyttäjäkohorttiin ja ketkä eivät. Tavoitteena on tehdä määrittelyprosessista (”Kuka sai mitä?” ja ”Sitten tapahtui tämä”) automaattinen ja jatkuva.
4. Vertaile kunkin kohortin piiriin kuuluvien ja sieltä poistettujen metriikkamalleja merkittävien erojen tunnistamiseksi (ja valinnaisesti varoittamiseksi). Olet ehkä nähnyt tämän mallin ennenkin ”A/B-testauksen” yhteydessä, jossa tyypillisesti seurataan muutosten vaikutusta konversiometriikkaan, mutta tässä puhutaan laajasti kaiken suunnittelutyön vaikutusten seurannasta ja siitä, että seuraamme jatkuvasti valppaasti vaikutuksia kaikkiin organisaation arvostamiin metriikoihin riippumatta siitä, onko vaikutusta näihin metriikoihin odotettu vai ei.

Progressiivinen toimitus: RedMonkin analyytikko James Governor on keksinyt termin progressiivinen toimitus. Useat kaupalliset ominaisuuslipputoimittajat tarjoavat näitä ominaisuuksia valmiiksi, ja on syntymässä yksimielisyys siitä, että ominaisuusliput ovat liittyneet niiden kehittäjätyökalujen joukkoon, joita on järkevämpää ostaa kuin rakentaa ja ylläpitää itse.

Ominaisuusliput ovat olennainen perusta sujuvuuden saavuttamiselle, mutta yksinään ne eivät nopeuta vaikutusten havaitsemista. Useimmat ominaisuuslipputoteutukset helpottavat virtausta, mutta eivät tee mitään osoittaakseen, onko kaikki hyvin tai saavutetaanko mielekkäitä tuloksia.

Head’s Up: Data Scientists Don’t Scale

Systeemi- ja käyttäjäkäyttäytymisen hahmottaminen ja automaattinen sovittaminen altistuviin kohortteihin on harvinaista kaikissa muissa kuin kaikkein kehittyneimmissä talon sisäisissä järjestelmissä. Useimmat tiimit, jotka yrittävät tätä käytäntöä, tekevät paljon manuaalista ja tilapäistä datatieteellistä työtä. Koska henkilöstöresursseja on rajoitettu enemmän kuin laskentakapasiteettia, niiden on pakko valita, milloin ja mihin kiinnittää huomiota.

Kognitiivinen kuormitus ei ole ystäväsi, kun tavoitellaan virtausta, joten Splitin suunnittelussa ei edes vaadita tiimejä valitsemaan, mitkä tapahtumat liitetään kuhunkin ominaisuuslippujen käyttöönottoon; kaikki syötetyt tapahtumat, kun ne on kerran sidottu organisaatiomittareihin, liitetään jatkuvasti jokaisen käyttöönoton on- ja off-kohortteihin ilman mitään toimenpiteitä. Split helpottaa myös tapahtumatietojen tunnistamista ja tallentamista Segment-, Sentry-, mParticle- ja Google Analytics -integraatioiden avulla.

Semper Fi for Continuous Delivery Pipelines

Mittareiden mallien vertailu kuhunkin kohorttiin kuuluvien ja kuulumattomien välillä tiukalla tavalla merkittävien erojen automaattiseksi määrittämiseksi on luonnossa vielä harvinaisempaa kuin attribuutio. Juuri tämän ongelman Splitin Monitor- ja Experimentation-moduulit ratkaisevat. Monitor keskittyy tunnistamaan ja varoittamaan mittareihin kohdistuvista vaikutuksista, kun käyttöönotto on käynnissä (tunnetaan myös nimellä ”vaaratilanteiden räjähdysalueen rajoittaminen”), kun taas Experimentation pyrkii A/B-testien tapaan tarjoamaan jatkuvan puolueettoman tiedonlähteen, jota ei rajoita analyytikon saatavuus ja joka osoittaa, saavutettiinko kullakin ominaisuudella haluttu vaikutus vai ei.

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

Miksi pyrimme virtaukseen? Kyse ei ole tuotoksesta. Kyse on tuloksista. Pyrimme virtaukseen, jotta voimme iteroida idean -> toteutus -> havainnointi -> palautesilmukan vähemmällä kitkalla ja lyhyemmässä ajassa. Kutsuttiinpa sitä sitten ”vaikutuslähtöiseksi kehittämiseksi” tai ”asiakaslähtöiseksi kehittämiseksi”, tämä lähestymistapa nopeampaan etenemiseen ja suurempaan (ja nopeampaan) tietoisuuteen tuloksista menee paljon pidemmälle kuin ”käyttöönottoputki huonojen muutosten havaitsemiseksi ja hylkäämiseksi”, jonka DORA-tiimi suositteli yhdistettäväksi vertaisarviointikäytäntöihin. Kyllä, voimme automaattisesti havaita ja hylätä huonoja muutoksia, mutta vielä tärkeämpää on se, että voimme rakentaa toistettavan prosessin, jonka avulla voimme trianguloida kohti mielekkäitä liiketoimintatuloksia.

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

• Katso neliminuuttinen video Jatkuvan toimituksen (Continuous Delivery) määritelmästä nähdäksesi, miksi pieni eräkoko on kriittinen johdonmukaisen sujuvuuden saavuttamisessa.
• Poimi vinkkejä useilta tiimeiltä, jotka toimittavat tuotantoon päivittäin, O’Reillyn e-kirjasta Continuous Delivery in the Wild
• Katsele Craig Sebenikin (LinkedIn, Crunchbase, Matterport) kanssa tehty perusteellinen video, jossa kerrotaan runkopohjaiseen kehitykseen siirtymisen hyödyistä.

Etsitkö lisää loistavaa sisältöä siitä, miten saavutetaan mielekkäitä tuloksia mittakaavassa tapahtuvalla ominaisuuksien toimituksella? Kirjanmerkitse Splitin blogi, tutustu meihin YouTubessa tai seuraa meitä Twitterissä @splitsoftware.