Julkaisujen hallinta

Julkaisuhallinta on ohjelmistomuutosten tuotantoon siirtymisen suunnittelun, aikataulutuksen ja hallinnan ala. Se kattaa julkaisun sisällön, sen varmentamisen, käyttöönoton, jälkivalvonnan ja korjaukset, jos jokin menee pieleen. Sen tavoitteena on tehdä siirtymisestä rakennettua versiota tuotantoon rutiininomaisesti eikä tapahtumaköyhästi.

Johdonmukaisin löydös tällä alueella on ristiriidassa intuition kanssa. Suuret versiot tuntuvat turvallisemmilta, koska ne keskittävät riskin yhteen huolellisesti hallittuun tapahtumaan, mutta toimituskykytutkimuksen todisteet viittaavat toiseen suuntaan: usein julkaistavat pienet versiot tuottavat alhaisempia virhemääriä ja nopeamman toipumisen. Suuri versio sisältää useita muutoksia, joten kun jokin rikkoutuu, syytä on vaikea eristää, ja peruutus hylkää kaiken eikä yhtä viallista muutosta.

Käyttöönoton automatisointi on perusta, joka mahdollistaa tiheyden. Manuaaliset käyttöönottomenettelyt ovat hitaita, epäjohdonmukaisia ​​ja virhealttiita, ja niiden kustannukset julkaisua kohden luovat painetta erämuutoksille, mikä tuottaa juuri ne suuret julkaisut, joihin liittyy enemmän riskiä. Putken automatisointi siten, että käyttöönotto on toistettavissa ja merkityksetön, poistaa kannustimen kasaantumiseen.

Käyttöönoton ja julkaisun erottaminen on tekniikka, joka muuttaa riskiprofiilia eniten. Koodin käyttöönotto tuotantoympäristöön ominaisuus poistettuna käytöstä lipun takana ja sen erillinen käyttöönotto tarkoittaa, että koodin tekninen toimitus ja toiminnallisuuden paljastaminen eivät enää tapahdu samaan aikaan. Käyttöönoton ongelmat havaitaan ilman, että ne vaikuttavat käyttäjiin, ja ominaisuuksia voidaan paljastaa asteittain ja poistaa välittömästi ilman, että mitään tarvitsee ottaa uudelleen käyttöön.

Progressiivinen altistuminen seuraa luonnollisesti tästä eriyttämisestä. Julkaisemalla pienelle prosenttiosuudelle liikenteestä, seuraamalla virhemääriä ja liiketoimintamittareita sekä laajentamalla asteittain minkä tahansa ongelman leviämisaluetta pieneen osaan käyttäjistä. Tämä on huomattavasti tehokkaampaa kuin laajat julkaisua edeltävät testaukset sellaisten ongelmaluokkien havaitsemisessa, jotka ilmenevät vain todellisissa tuotanto-olosuhteissa, kuormituksella ja datalla.

Palautusmahdollisuus on pikemminkin varmistettava kuin oletettava, ja juuri tässä kohtaa monet organisaatiot löytävät ongelman pahimmalla mahdollisella hetkellä. Dokumentoitu palautusmenettely, jota ei ole koskaan toteutettu, epäonnistuu usein tarvittaessa, erityisesti silloin, kun kyseessä ovat tietokantasiirrot ja kaavamuutosta ei voida yksinkertaisesti peruuttaa. Palautusten harjoittelu ja siirtojen suunnittelu taaksepäin yhteensopiviksi, jotta edellinen versio toimii edelleen, tekee turvaverkosta todellisen.

Julkaisun jälkeinen seuranta on osa prosessia eikä erillinen asia. Julkaisu ei ole valmis, kun käyttöönotto onnistuu; se on valmis, kun järjestelmän on havaittu toimivan oikein todellisessa liikenteessä. Määrittelemällä etukäteen, mitä indikaattoreita seurataan, kuinka kauan ja mikä kynnys laukaisee peruutuksen, julkaisun jälkeinen ajanjakso muuttuu epämääräisestä valppaudesta määritellyksi vaiheeksi, johon liittyy päätös.

Julkaisuihin liittyvä viestintä on tärkeämpää kuin tiimit odottavat, erityisesti silloin, kun muutokset ovat näkyviä asiakkaille tai vaikuttavat sisäisiin käyttäjiin, joiden on valmistauduttava. Tukitiimien on tiedettävä, mikä muuttui, ennen kuin asiakkaat kysyvät, ja ilmoittamattomat käyttöliittymämuutokset tuottavat yhteydenottojen määrän suhteettoman paljon niiden kokoon nähden. Lyhyt ja luotettava ilmoitus, joka tavoittaa kysymyksiin vastaavat henkilöt, maksaa vähän ja estää ennustettavissa olevat häiriöt.

Koska julkaisukäytäntö määräytyy yhtä lailla taustalla olevan toimitusinfrastruktuurin kuin prosessinkin mukaan, parantaminen vaatii yleensä teknisiä investointeja pikemminkin kuin menettelytapoja koskevia muutoksia. Käytännössä tämä vakiintuu tuotekehitys, levittämisen jälkeinen seuranta perustuu mittauksiin, joita ylläpidetään data-analytiikka jotta liiketoimintavaikutuksia ei tarkastella pelkästään teknisen kunnon perusteella, ja useita palveluita hallinnoivissa organisaatioissa standardit ovat tyypillisesti kaikkien vastuulla. IT-osasto sen sijaan, että asetettaisiin joukkue joukkueelta.