8 vaihetta Agile-tiimien ohjelmistojulkaisujen hallintaan

Lisäksi suurissa yrityksissä, joissa on aiemmin työskennelty perinteisemmillä vesiputousmenetelmillä, syntyy usein tietosiiloja. Agile-työskentely on avain niiden purkamiseen, mutta se ei tapahdu yhdessä yössä. Yksi tiimi ei aina tiedä, mitä toinen tekee. Yhden tiimin prosessit voivat hyödyttää toista merkittävästi, mutta tiimi ei yksinkertaisesti tiedä niistä. Jos tietoa ei dokumentoida perusteellisesti, seurauksena voi mielestäni olla hämmennystä ja tehottomuutta.

Tässä artikkelissa annan vinkkejä julkaisuprosessin virallistamiseen erityisesti kehittäjän näkökulmasta.

Osa 1: Ohjelmistojulkaisujen hallinnan tarkistuslista

Osa 2: Parhaiden käytäntöjen omaksuminen

Osa 3: Continuous Integration

Ohjelmistojulkaisujen hallinnan tarkistuslista

Tässä osiossa ehdotan vaiheita, joiden avulla voit luoda oman tarkistuslistasi julkaisuprosessia varten. Osa vaiheista ei missään nimessä ole pakollisia. Jokainen sovellus on erilainen, ja jokainen tiimi työskentelee eri tavoin, joten mukauta ja tee muutoksia, jotka sopivat paremmin työnkulkuusi.

1. Luo release-haara

Git Workflow -käsite tai release-haarojen idea on sinulle todennäköisesti tuttu.

Ihannetilanteessa käytössäsi on vähintään kolme haaraa:

• master: tämän tulisi vastata tuotantoympäristössä olevan version nykytilaa. Jokaisen uuden master-haaraan tehdyn commitin tulisi muodostaa vain yksi uusi julkaisu.

• develop: tämän haaran tulisi sisältää valmiit ja testatut tulevat ominaisuudet. Yleinen käytäntö on luoda jokaiselle ominaisuudelle oma haara ja yhdistää se develop-haaraan, kun ominaisuus on valmis.

• release: release-haarat ovat kokoelma tuotantoon lähetettäviä committeja sekä julkaisuun liittyviä pieniä virheenkorjauksia.

Huomaa, että release-haarat tulee poistaa, kun julkaisu on valmis. Siksi näitä haaroja luodaan ja poistetaan jatkuvasti, toisin kuin master- ja develop-haaroja, jotka pysyvät samoina.

Luo uusi release-haara develop-haarasta git-päätteessä kirjoittamalla:

$ git checkout -b release/x.y.z

On kätevää käyttää nimeämiskäytäntöä, kuten yllä määriteltyä, jossa x.y.z korvataan tarpeisiisi sopivalla major.minor.patch-versionumerolla. Käytäntö kannattaa määritellä tiimissä ja noudattaa sitä.

On myös tärkeää huomata, että jos teet virheenkorjauksia release-haaraan, muista yhdistää ne takaisin develop-haaraan. Release-haaran pääasiallinen tarkoitus on tarjota esikatselutilanne siitä, miten sovelluksen tulisi toimia tuotantoon siirron jälkeen.

Eri release-haarojen organisointi ja seuranta on olennainen osa julkaisujen hallintaa.

2. Päivitä versionumero

Seuraavaksi päivitä release-haaran versionumeroa.

Avaa projektistasi AndroidManifest.xml / package.json / pom.xml tai muu tiedosto, johon sovelluksen versio on tallennettu (käytännöt vaihtelevat), päivitä versionumero ja commitoi muutokset nykyiseen release-haaraan.

Versionumeron päivittäminen on tärkeää kahdesta syystä.

Ensinnäkin voit seurata ja yhdistää kuhunkin versioon lisätyt ominaisuudet. Toiseksi tiedät, mitä versiota käyttäjät käyttävät, jos heidän täytyy selvittää ongelmia tai ottaa yhteyttä tukeen. Jos kehität mobiilisovellusta, tässä vaiheessa päivitettävä versionumero näkyy yleensä käyttäjälle Tietoja-osiossa tai Google Playssa tai Apple App Storessa. Tämä vaihe on myös hyvä tilaisuus päivittää ympäristöriippuvaisia konfiguraatiotiedostoja – vaikka suosittelen säilyttämään ne erillisessä repositoriossa – esimerkiksi niin, että haara osoittaa tuotantotietokantaan, sekä tehdä muita build-prosessin vaatimia muutoksia.

Lopuksi on suositeltavaa pushata release-haara originiin, jotta se on muiden kehittäjiesi käytettävissä:

$ git push -u origin release/x.y.z

3.a) Yhdistä release-haara master-haaraan ja taggaa se

Tuotantoon tulisi ottaa käyttöön vain master-haara, joten tässä vaiheessa release-haara on yhdistettävä master-haaraan.

$ git checkout master
																				$ git merge --no-ff release/x.y.z
																				$ git push

--no-ff-valitsin on valinnainen. Sen käyttöä kuitenkin suositellaan, jotta uusi commit-objekti luodaan, vaikka yhdistäminen olisi mahdollista tehdä fast-forward-tekniikalla.

Seuraavaksi on aika tagata release master-haarassa:

$ git tag -a x.y.z -m 'description of new version, features or fixes included'

Tagit ovat hyödyllisiä, koska ne tallentavat tietyn kohdan git-repositorion historiassa. Voit myöhemmin palata siihen ja luoda erillisen haaran tietystä tagista.

3.b) Yhdistä release-haara pull requestin avulla

Toinen usein käytetty vaihtoehto on yhdistää release-haara master-haaraan pull requestin avulla.

Tässä lähestymistavassa on monia etuja. Se luo uuden tilan yhteistyölle, jossa tiimi voi keskustella eri releaseen liittyvistä asioista. Tässä vaiheessa kannattaa lisätä ylimääräinen tarkistuspiste code review -prosessille: useammat silmäparit voivat tarkastella käyttöön tulevaa koodia ja keskustella mahdollisista muutoksista.

Työkaluja, joilla voit ottaa pull requestit osaksi työnkulkujasi, ovat esimerkiksi GitHub ja Bitbucket. Näissä työkaluissa git-komentoja ei kirjoiteta manuaalisesti. Sen sijaan valitset verkkokäyttöliittymässä lähdehaaran (release) ja kohdehaaran (master) sekä lisäät yhden tai useamman tarkastajan. He voivat kirjoittaa rivikohtaisia kommentteja uusiin muutoksiin, ehdottaa parannuksia ja niin edelleen.

Kun kaikki tarkastajat ovat hyväksyneet pull requestin, voit yhdistää muutokset automaattisesti master-haaraan painamalla käyttöliittymässä olevaa painiketta.

4. Ota master käyttöön tuotantoympäristössä

Tässä vaiheessa on hyvä käytäntö, että tiimisi testaaja tekee smoke-testin (joka voidaan määritellä erillisessä tarkistuslistassa) ennen käyttöönottoa. Hyvä tapa on ottaa master-haara käyttöön erillisessä testiympäristössä. Testaaja voi sitten tehdä joitakin perustoimintoja varmistaakseen, ettei viimeisimpään buildiin tullut mitään vikaa yhdistämisen jälkeen. Smoke-testin tekeminen ei kuulu tämän artikkelin aihepiiriin, mutta verkosta löytyy siitä runsaasti materiaalia. Smoke-testin tulos voidaan lisätä releasen tarkistuslistaan tai taulukkoon, johon dokumentoidaan mahdolliset ongelmat.

Nyt olet valmis ottamaan muutokset käyttöön ja julkaisemaan ne. Ota master-haara käyttöön.

Muista varmistaa, että käyttöönotto onnistui ja kaikki toimii odotetusti.

5. Yhdistä muutokset takaisin develop-haaraan ja poista release-haara

Release on nyt lähes valmis. Yhdistä release-haara develop-haaraan, jotta versionumero päivittyy develop-haarassa ja kaikki korjaukset siirtyvät pääkehityshaaraan:

$ git checkout develop
																				$ git merge release/x.y.z

Nyt on aika poistaa release-haara:

$ git branch -d release/x.y.z

6. Muutoslokin luominen

Projektisi juurikansiossa tulisi olla CHANGELOG.md-tiedosto (tai vastaava), johon lisäät uuden merkinnän jokaisen releasen yhteydessä. Näin dokumentoit releasen sisällön, kuten virheenkorjaukset, uudet ominaisuudet, tunnetut ongelmat ja muut olennaiset tiedot release notes -muodossa. Tämä on erittäin hyödyllistä käyttäjille ja osallistujille, sillä he näkevät, mitä muutoksia projektin eri releasejen (tai versioiden) välillä on tehty.

Muutoslokimerkintä sisältää päivämäärän, versionumeron ja muistiinpanoja releasesta. Merkinnät tulisi pitää käänteisessä aikajärjestyksessä. Tässä on yksinkertainen malli, jota olen käyttänyt ja jonka voit mukauttaa projektiisi:

<app's name or component released>  |
																				<developer's name in charge of release> | <developer's email>
																				Features:
																				* <ticket/issue number>: <ticket/issue summary> ()
																				* ...
																				Bugs fixed:
																				* <ticket/issue number>: <ticket/issue summary> ()
																				* ...
																				Enhancements:
																				* <ticket/issue number>: <ticket/issue summary> ()
																				* ...
																				Optional: known issues plus other release notes.

Lisäksi tämän vaiheen voi automatisoida kokonaan kirjoittamalla yksinkertaisen skriptin, joka käy läpi git login ja luo muutoslokimerkinnän automaattisesti. Huomaa kuitenkin, että automaation taso on suoraan verrannollinen commit-viestien muodon yhdenmukaisuuteen. On aina hyvä käytäntö sopia tiimin kanssa tietystä commit-viestien muodosta. Kun commit-viestien tyyliohjeita noudatetaan, viestejä on helpompi jäsentää ja muutoslokin luominen voidaan todennäköisemmin automatisoida.

7. Viesti sidosryhmille

Tärkeintä on muistaa viestiä, että uusi release on saatavilla.

Voit esimerkiksi ilmoittaa tiimeillesi sisäisen viestintätyökalun, kuten HipChatin, kautta, että uusi release on valmistunut. Suosittelen luomaan erillisen huoneen (esim. Releases) vain releaseihin liittyvien tapahtumien viestintää varten. HipChatin JIRAn ja Bitbucketin kaltaisiin kehitystyökaluihin tarjoamien integraatioiden ansiosta voit jopa määrittää tätä varten automaattisia hälytyksiä.

Vaihtoehtoisesti voit kirjoittaa blogikirjoituksen joko sisäisesti Confluenceen tai julkiseen blogiisi tai ilmoittaa releasesta sosiaalisessa mediassa. Organisaatiosi luonteesta riippuen voit tehdä myös muita toimenpiteitä.

8. Issue trackerin ylläpito

Releasen jälkeen sinun on todennäköisesti päivitettävä joidenkin tikettien tilaa, jotta pysyt ajan tasalla tuotannossa olevista bugikorjauksista ja ominaisuuksista. Yleensä tämä tarkoittaa joidenkin tagien muuttamista. Pienissä projekteissa käytän release-pending -tagia, jonka poistan releasen valmistuttua.

Jos käytät milestoneja jokaiselle uudelle versiolle, sinun on todennäköisesti päivitettävä niiden tila tai merkittävä ne valmiiksi. JIRA Software -tyyppisten issue trackerien avulla voit jopa suunnitella releasen ja sovittaa sen sprintteihin, seurata, estääkö jokin bugi releasen, sekä nähdä muuta hyödyllistä tietoa.

Kaikki riippuu siitä, miten käytät työkalua. Haluan vain korostaa, että issue trackerin tietojen päivittäminen kannattaa sisällyttää release-tarkistuslistaan.

Release-prosessin automatisoinnista

Olet ehkä huomannut, että edellä kuvattua changelog-vaihetta lukuun ottamatta myös monet aiemmin mainituista vaiheista voidaan automatisoida.

Mahdollisuus automatisoida release-prosessin osia on suuri etu ja säästää paljon aikaa. Suosittelen luomaan skriptejä tai selvittämään, miten yksittäisiä vaiheita voi automatisoida, ja etenemään kohti Continuous Deliveryä. Näin voit pienentää riskejä ja kustannuksia sekä vähentää aikaa, jonka kehittäjät käyttävät releasen hallintaan. Sen ansiosta voit julkaista useammin ja käyttää kehitykseen varatun ajan tuottavammin.

DevOpsin pyhä graali on mahdollisuus julkaista uusi versio painamalla painiketta tai suorittamalla komento, joka käynnistää release-prosessin automaattisesti. Vielä parempi olisi järjestelmä, joka julkaisee ohjelmistosi uuden version ennalta määritettynä ajankohtana. Tämän saavuttaminen on vaikeaa, sillä myös suuri osa testausprosessista on automatisoitava, mutta se ei ole mahdotonta tai niin kaukaa haettua kuin jotkut ajattelevat.

Parhaiden käytäntöjen omaksuminen

Tässä osiossa kuvaan muutamia suositeltuja käytäntöjä, jotka olen havainnut hyödyllisiksi joko release-prosessin sujuvoittamisessa tai varotoimina siltä varalta, että jokin menee pieleen.

Julkaise sopivimpana päivänä

Julkaisen yleensä kehittämäni sovellukset torstaisin keskipäivän ja työpäivän päättymisen välillä.

Jos työskentelet maanantaista perjantaihin, julkaisu perjantaina ei ole hyvä idea. Jos jokin hajoaa releasen jälkeen, et ehdi korjata sitä ennen maanantaita, ellet halua työskennellä viikonloppuna. Siksi releaset kannattaa tehdä torstaisin: perjantaina voit seurata käyttöönotettua uutta versiota ja korjata mahdolliset ongelmat tai tehdä tarvittaessa rollbackin.

On myös tärkeää tietää, millä aikavyöhykkeellä suurin osa käyttäjistäsi sijaitsee. Julkaisu kannattaa ajoittaa vähäisen liikenteen aikaan, jotta mahdollisen virheen aiheuttamat haitat jäävät mahdollisimman pieniksi. Tämä voi olla hankalaa, kun käyttäjäkunta on levittäytynyt ympäri maailmaa, mutta asia kannattaa aina selvittää ja valita paras mahdollinen ajankohta.

Varmuuskopioi tietokantasi ennen uutta releasea

Jos et jo tee tietokannastasi säännöllisiä varmuuskopioita, suosittelen vahvasti lisäämään release-prosessiisi vaiheen, joka muistuttaa varmuuskopion ottamisesta ennen releasen aloittamista.

Vaiheittaiset julkaisut

Oletko koskaan ihmetellyt, miksi uuden ominaisuuden julkaissut yritys kertoo siitä, mutta ominaisuus tulee saataville puhelimeesi vasta päivien tai jopa viikkojen kuluttua? Syy on se, että monet yritykset käyttävät vaiheittaisia julkaisuja.

Facebook on tehnyt näin jo pitkään. Se testaa uutta ominaisuutta viidellä tai kymmenellä prosentilla käyttäjistään ja kasvattaa osuutta vähitellen, kunnes ominaisuus on käytössä sadalla prosentilla käyttäjäkunnasta. Vaiheittaisen julkaisun aikana käyttäjäpalautetta ja kaatumisraportteja on seurattava tarkasti. Näiden tietojen avulla voit lykätä julkaisua tai korjata virheet ennen kuin ne vaikuttavat kaikkiin käyttäjiin.

Continuous Integration

Continuous Integration on käytäntö, joka kannattaa omaksua monesta syystä. Ensinnäkin se auttaa havaitsemaan virheet varhain ja kasvattaa onnistuneiden releasejen määrää. Toiseksi se on ensimmäinen looginen askel kohti aiemmin kuvattua Continuous Deliveryä ja täyttä automaatiota.

Aihe on laaja, ja siitä on kirjoitettu paljon kirjoja ja blogikirjoituksia, mutta mainitsen sen tässä, koska uskon sen lisäävän huomattavasti luottamustasi toimintaasi. CI:n monien hyötyjen joukossa ovat pienemmät riskit, parempi näkyvyys siihen, mikä toimii ja mikä ei, bugien aiempi havaitseminen, käyttöönottojen tihentyminen ja paljon muuta.

CI:n käyttöönotto alkaa “Continuous Integration -palvelimen” perustamisesta. Kokeilemisen arvoisia työkaluja ovat esimerkiksi Bamboo, Jenkins ja Travis.

Loppukevennys: Kaikki järjestyy

Lopuksi toteaisin, että hyvin määritelty julkaisuprosessi on erittäin tärkeä riippumatta sen monimutkaisuudesta, käyttäjäkunnasta tai organisaatiosi koosta.

Jos sellaista ei ole, suosittelen miettimään perusvaiheita. Käytä tätä ja muita vastaavia oppaita apuna, kun ideoitte tiimisi kanssa ensimmäistä luonnosta. Kokeile sitä seuraavan julkaisun yhteydessä ja kehitä sitä sitten edelleen. Lopulta rakennat oman julkaisuprosessisi.

Sen jälkeen ala miettiä, miten automatisoit osia prosessista. Pohdi, mitä osa-alueita voi parantaa. Selvitä, miten voit lyhentää julkaisuaikaa pienillä optimoinneilla. Automaation tulisi olla lopullinen tavoitteesi, mutta älä suunnittele sitä heti alusta alkaen, sillä näin suuren harppauksen yrittäminen voi johtaa epäonnistumiseen. Kuten kaikkia prosesseja, myös tätä kannattaa kehittää vähitellen.