Azure DevOps -palvelut ja CI/CD-automaatio
Azure DevOps on Microsoftin työkaluperhe ohjelmistokehityksen hallintaan. Siihen kuuluu viisi osaa: Azure Repos versionhallintaan, Azure Pipelines CI/CD-putkiin, Azure Boards työnohjaukseen, Azure Test Plans testaukseen ja Azure Artifacts pakettien hallintaan. Nämä voi ottaa käyttöön erikseen tai yhdessä.
Monessa organisaatiossa Azure DevOps on jo käytössä jossain muodossa. Kysymys ei ole siitä, pitäisikö se ottaa käyttöön, vaan siitä, tehdäänkö sillä oikeita asioita. Tässä tekstissä käydään läpi, mitä Azure DevOpsilla voi tehdä, missä menee pieleen ja milloin se ei ole oikea valinta.
Mitä Azure DevOps oikeastaan ratkaisee
- Ohjelmistokehityksessä on kolme ongelmaa jotka toistuvat riippumatta siitä, millä työkaluilla työtä tehdään.
- Ensimmäinen on se, että koodi on hajallaan. Joku tallentaa sen omalle koneelleen, joku toinen jakaa sen sähköpostilla, kolmas pitää sitä verkkoasemalla. Kun pitää tietää, mikä versio on tuotannossa, kukaan ei osaa vastata.
- Toinen on se, että julkaisu on manuaalinen prosessi. Joku kopioi tiedostoja palvelimelle, ajaa komentoja käsin ja toivoo, että kaikki menee hyvin. Yleensä menee, kunnes ei mene.
- Kolmas on se, että kukaan ei tiedä, mitä ollaan tekemässä. Tiketit ovat yhdessä paikassa, koodi toisessa, keskustelut kolmannessa. Kokonaiskuva puuttuu.
- Azure DevOps ratkaisee nämä kolme asiaa. Se ei ratkaise kaikkia ongelmia, mutta se antaa yhden paikan, jossa koodi, työtehtävät ja julkaisuprosessi ovat samassa järjestelmässä.
Azure Repos – versionhallinta
Azure Repos tukee kahta versionhallintajärjestelmää: Gitiä ja TFVC:tä. TFVC on Microsoftin vanha järjestelmä, ja sitä käytetään enää harvoin uusissa projekteissa. Git on käytännössä ainoa vaihtoehto, jota kannattaa harkita.
Git on Git. Sama työkalu toimii Azure Reposissa, GitHubissa, GitLabissa ja Bitbucketissa. Ero on siinä, miten se integroituu muuhun työkaluperheeseen.
Azure Reposissa on yksi ominaisuus, joka erottaa sen GitHubista: se on osa samaa järjestelmää Pipelinesin, Boardsin ja Artifactsien kanssa. Pull requestissa voi nähdä suoraan, mitkä työtehtävät siihen liittyvät, mitkä testit ovat menneet läpi ja mitä versioita siitä on julkaistu. Tämä ei ole mullistavaa, mutta se vähentää sitä työtä, jota ihmiset tekevät käsin.
Yksi asia, joka kannattaa päättää heti alussa: käytetäänkö branch policyja. Branch policyt ovat sääntöjä, jotka määrittelevät, mitä pull requestilta vaaditaan ennen kuin se voidaan yhdistää. Pakolliset katselmoinnit, pakolliset buildit, pakolliset testit. Jos näitä ei oteta käyttöön heti, niitä on vaikea lisätä myöhemmin, koska ihmiset ovat jo tottuneet siihen, että pull requestit menevät läpi ilman esteitä.
Azure Pipelines – CI/CD
Tämä on se osa, josta useimmat organisaatiot aloittavat. Ja tämä on myös se osa, jossa useimmat tekevät samoja virheitä.
Azure Pipelines tukee kahta tapaa määritellä putkia: klassinen editori ja YAML. Klassinen editori on graafinen käyttöliittymä, jossa putki rakennetaan klikkailemalla. YAML on tekstitiedosto, joka on repossa muun koodin kanssa.
Suosittelemme YAML:ia. Tämä ei ole mielipidekysymys vaan käytännön kysymys. YAML-putki on versiohallittu, se on katselmoitavissa kuten koodi, ja se on siirrettävissä repositoriosta toiseen. Klassinen editori ei tarjoa näitä ominaisuuksia.
Tyypillinen putki, jonka rakennamme, näyttää tältä.
Ensin ajetaan koodin laadun tarkistukset. Lintterit, staattinen analyysi, muototarkistukset. Nämä ovat nopeita ja ne kaappaavat yksinkertaiset virheet ennen kuin kukaan ehtii katsoa koodia.
Sen jälkeen ajetaan yksikkötestit. Jos ne eivät mene läpi, putki pysähtyy tähän.
Sitten rakennetaan artefakti. Tämä on se paketti, joka viedään eteenpäin. Se voi olla Docker-image, npm-paketti, JAR-tiedosto tai mitä tahansa muuta.
Sitten ajetaan integraatiotestit. Nämä ovat hitaampia kuin yksikkötestit ja ne vaativat yleensä ympäristön, jossa on tietokanta ja muita palveluita.
Lopuksi julkaistaan. Tämä tapahtuu yleensä eri vaiheessa, ja se vaatii hyväksynnän, jos kyseessä on tuotantoon menevä julkaisu.
Tämä on perusrunko. Jokainen projekti muokkaa sitä tarpeidensa mukaan.
- Putket ajetaan agenteilla. Microsoft tarjoaa ilmaisia hostattuja agentteja, jotka ovat käytössä rajoitetun määrän kuukaudessa. Tämän jälkeen pitää joko maksaa lisää tai ottaa käyttöön omat agentit.
- Omat agentit ovat virtuaalikoneita, jotka pyörivät omassa infrastruktuurissa tai Azuressa. Ne ovat hyödyllisiä silloin, kun tarvitaan erityisiä työkaluja, kun pitää päästä käsiksi sisäverkkoon tai kun halutaan hallita kustannuksia tarkemmin.
- Omiin agentteihin liittyy yksi asia, joka yllättää monen. Niitä pitää ylläpitää. Ne pitää päivittää, ne pitää mitoittaa oikein, ja ne pitää suojata. Tämä on työtä, jota ei ole hostatuilla agenteilla.
Agentit:
- Azure Pipelines tukee ympäristöjä, jotka ovat loogisia paikkoja, joihin julkaisut menevät. Kehitys, testi, staging, tuotanto. Jokaiselle ympäristölle voi määritellä hyväksyntöjä, jotka pitää täyttää ennen kuin julkaisu etenee.
- Hyväksynnät voivat olla manuaalisia, jolloin joku hyväksyy julkaisun käsin. Ne voivat olla myös automaattisia, jolloin julkaisu etenee, jos tietyt ehdot täyttyvät.
- Suosittelemme, että tuotantoon menevä julkaisu vaatii aina manuaalisen hyväksynnän. Tämä ei ole siksi, että prosessi olisi hidas, vaan siksi, että joskus on hyvä pysähtyä ja katsoa, mitä ollaan tekemässä.
Ympäristöt ja hyväksynnät:
Azure Boards – työnohjaus
- Azure Boards on työkalu työtehtävien hallintaan. Se tukee useita prosessimalleja: Agile, Scrum, CMMI ja Basic. Useimmat organisaatiot käyttävät Agilea tai Scrumia.
- Se, mikä erottaa Azure Boardsin Jirasta, on integraatio muuhun Azure DevOpsiin. Kun työtehtävä on merkitty valmiiksi ja siihen liittyvä pull request on yhdistetty, työtehtävä päivittyy automaattisesti. Tämä ei ole mullistavaa, mutta se vähentää manuaalista työtä.
- Boardsin käyttöönotossa on yksi asia, joka kannattaa tehdä huolella: työnkulkujen määrittely. Jos työnkulut ovat liian monimutkaisia, ihmiset alkavat kiertää niitä. Jos ne ovat liian yksinkertaisia, ne eivät vastaa todellisuutta.
- Tyypillinen virhe on se, että kopioidaan Jiran työnkulut sellaisenaan ja yritetään sovittaa ne Boardsiin. Nämä ovat eri työkaluja, ja niiden vahvuudet ovat eri paikoissa. Boards toimii parhaiten, kun työnkulut ovat yksinkertaisia ja kun integraatio koodiin on keskeistä.
Azure Test Plans – testaus
Azure Test Plans on testauksen hallintaan tarkoitettu työkalu. Se tukee manuaalista testausta ja automaattista testausta.
Manuaalinen testaus on se osa, jota useimmat organisaatiot eivät käytä. Se on työläs ottaa käyttöön, ja se vaatii, että testitapaukset kirjoitetaan ylös ja niitä ylläpidetään.
Automaattinen testaus puolestaan on integroitu Pipelinesiin. Testit ajetaan osana putkea, ja tulokset näkyvät samassa paikassa kuin muutkin tulokset.
Suosittelemme yleensä, että Test Plans otetaan käyttöön vain, jos manuaalinen testaus on oikeasti tarpeen. Tämä on harvinaisempaa kuin miltä näyttää. Useimmissa projekteissa automaattiset testit riittävät, ja manuaalinen testaus tehdään epävirallisesti ilman erillistä työkalua.
Azure Artifacts – pakettien hallinta
Azure Artifacts on pakettien repositorio. Se tukee npm-, NuGet-, Maven-, Python- ja Universal-paketteja.
Käytännössä tämä tarkoittaa sitä, että kun putki rakentaa paketin, se julkaistaan Artifactsiin. Muut projektit voivat sitten hakea sen sieltä.
Tämä on hyödyllistä erityisesti silloin, kun organisaatiolla on useita projekteja, jotka jakavat yhteisiä kirjastoja. Ilman Artifactsia nämä kirjastot joko kopioidaan projektista toiseen tai niitä jaetaan epävirallisesti.
Artifacts on yksi niistä osista, joita monet eivät ota käyttöön, koska ne eivät ymmärrä mihin sitä tarvitaan. Se on ymmärrettävää. Mutta kun projekteja on enemmän kuin kaksi tai kolme, jaetut kirjastot alkavat olla ongelma. Silloin Artifactsista tulee hyödyllinen.
Missä menee pieleen
Olemme nähneet monta Azure DevOps -käyttöönottoa. Osa on mennyt hyvin, osa ei. Tässä on yleisimmät syyt epäonnistumiseen.
Putket on rakennettu käsin klikkailemalla. Ne toimivat, mutta kukaan ei tiedä, mitä ne tekevät, koska ne eivät ole versiohallinnassa.
Salaisuudet on tallennettu putkien muuttujiin. Ne näkyvät kaikille, joilla on pääsy putkeen. Oikea paikka salaisuuksille on Azure Key Vault tai vähintään Azure DevOpsin oma salaisuuksien hallinta.
Putket ajavat kaikki testit jokaisella commitilla. Tämä hidastaa kehitystä, koska jokainen commit odottaa kymmenen minuuttia. Testit pitää jakaa nopeisiin ja hitaisiin, ja hitaat ajetaan harvemmin.
Ympäristöjä ei ole eriytetty. Kehitys, testi ja tuotanto käyttävät samoja resursseja. Tämä on ongelma, koska testaus vaikuttaa tuotantoon.
Kukaan ei seuraa putkien kestoa. Putket hidastuvat hiljaa. Kun ne ovat hidastuneet tarpeeksi, ihmiset alkavat ohittaa niitä. Tämä on merkki siitä, että jotain pitää korjata.
Milloin Azure DevOps ei ole oikea valinta
- Azure DevOps ei ole oikea valinta, jos tiimi on pieni ja projekteja on vähän. GitHub on nykyään parempi valinta useimmissa tapauksissa. Se on yksinkertaisempi, se on halvempi, ja sen työkaluperhe on riittävä pienille tiimeille.
- Azure DevOps ei ole oikea valinta, jos organisaatio on jo sitoutunut GitLabiin tai Jenkinsiin eikä ole erityistä syytä vaihtaa. Työkalujen vaihtaminen on kallista, ja se pitää perustella muulla kuin sillä, että Azure DevOps on Microsoftin tuote.
- Azure DevOps ei ole oikea valinta, jos kukaan ei ylläpidä sitä. Putket vanhenevat. Agentit vanhenevat. Käyttöoikeudet kertyvät. Ilman säännöllistä ylläpitoa järjestelmä alkaa mätäntyä.
Keitä me olemme
Teemme tätä työtä itse. Emme alihanki projekteja eteenpäin. Se kuka myy on se joka tekee.
Kerromme rehellisesti, jos jokin ei ole realistista. Jos Azure DevOps ei ole oikea ratkaisu, sanomme sen. Jos nykyinen putki on riittävä eikä sitä kannata uudistaa, sanomme sen.
Emme myy sinulle sitä mitä et tarvitse.