Uuden projektijulkaisun tuominen tuotantoon edellyttää huolellista tasapainoa käyttöönottonopeuden ja ratkaisun luotettavuuden välillä. Slack arvostaa nopeita iteraatioita, lyhyitä palautejaksoja ja nopeaa vastausta käyttäjien pyyntöihin. Lisäksi yhtiöllä on satoja ohjelmoijia, jotka pyrkivät olemaan mahdollisimman tuottavia.
Materiaalin, jonka käännöksen julkaisemme tänään, kirjoittajat sanovat, että tällaisiin arvoihin pyrkivän ja samalla kasvavan yrityksen on jatkuvasti parannettava projektien käyttöönottojärjestelmää. Yrityksen tulee panostaa työprosessien läpinäkyvyyteen ja luotettavuuteen varmistaen, että nämä prosessit vastaavat projektin mittakaavaa. Täällä puhutaan Slackin kehittämistä työnkuluista ja joistakin päätöksistä, jotka saivat yrityksen käyttämään nykyistä projektien käyttöönottojärjestelmää.
Kuinka projektin käyttöönottoprosessit toimivat nykyään
Jokainen Slackin PR (pull request) on tarkistettava koodilla ja läpäistävä kaikki testit. Vasta kun nämä ehdot täyttyvät, ohjelmoija voi yhdistää koodinsa projektin päähaaraan. Tätä koodia käytetään kuitenkin vain Pohjois-Amerikan aikaa aukioloaikoina. Tämän seurauksena, koska työntekijämme ovat työpaikoillaan, olemme täysin valmiita ratkaisemaan odottamattomat ongelmat.
Suoritamme päivittäin noin 12 suunniteltua käyttöönottoa. Jokaisen käyttöönoton aikana käyttöönottopäälliköksi nimetty ohjelmoija on vastuussa uuden version saattamisesta tuotantoon. Tämä on monivaiheinen prosessi, joka varmistaa, että kokoonpano saadaan tuotantoon sujuvasti. Tämän lähestymistavan ansiosta voimme havaita virheet ennen kuin ne vaikuttavat kaikkiin käyttäjiimme. Jos virheitä on liikaa, kokoonpanon käyttöönotto voidaan peruuttaa. Jos tietty ongelma havaitaan julkaisun jälkeen, siihen voidaan helposti julkaista korjaus.
Checkpoint-järjestelmän käyttöliittymä, jota käytetään Slackin projektien käyttöönotossa
Uuden julkaisun tuotantoprosessin voidaan ajatella koostuvan neljästä vaiheesta.
▍1. Luodaan julkaisuhaara
Jokainen julkaisu alkaa uudella julkaisuhaaralla, pisteellä Git-historiassamme. Tämä mahdollistaa tunnisteiden määrittämisen julkaisulle ja tarjoaa paikan, jossa voit tehdä reaaliaikaisia korjauksia bugeihin, jotka löydettiin julkaisun valmisteluvaiheessa tuotantoon julkaisua varten.
▍2. Käyttöönotto lavastusympäristössä
Seuraava vaihe on ottaa kokoonpano käyttöön välipalvelimilla ja suorittaa automaattinen testi projektin yleiselle suorituskyvylle (savutesti). Lavastusympäristö on tuotantoympäristö, joka ei vastaanota ulkoista liikennettä. Tässä ympäristössä suoritamme ylimääräisiä manuaalisia testejä. Tämä antaa meille lisävarmuutta siitä, että muokattu projekti toimii oikein. Automaattiset testit eivät yksin riitä antamaan tätä luottamusta.
▍3. Käyttöönotto koiranruoka- ja kanarialaisympäristöissä
Käyttöönotto tuotantoon alkaa dogfood-ympäristöstä, jota edustaa joukko isäntiä, jotka palvelevat sisäisiä Slackin työtiloja. Koska olemme erittäin aktiivisia Slackin käyttäjiä, tämä lähestymistapa auttoi meitä havaitsemaan monia bugeja käyttöönoton alkuvaiheessa. Kun olemme varmistaneet, että järjestelmän perustoiminnallisuus ei ole rikki, kokoonpano otetaan käyttöön kanariaympäristössä. Se edustaa järjestelmiä, joiden osuus tuotantoliikenteestä on noin 2 %.
▍4. Asteittainen julkaisu tuotantoon
Jos uuden julkaisun seurantaindikaattorit osoittautuvat vakaiksi ja jos emme ole saaneet valituksia projektin käyttöönoton jälkeen Canary-ympäristössä, jatkamme tuotantopalvelimien siirtämistä asteittain uuteen julkaisuun. Käyttöönottoprosessi on jaettu seuraaviin vaiheisiin: 10%, 25%, 50%, 75% ja 100%. Tämän seurauksena voimme hitaasti siirtää tuotantoliikennettä järjestelmän uuteen versioon. Samalla meillä on aikaa tutkia tilannetta, mikäli poikkeavuuksia havaitaan.
▍ Mitä jos jokin menee vikaan käyttöönoton aikana?
Koodimuutosten tekeminen on aina riski. Mutta selviämme tästä hyvin koulutettujen "käyttöönottojohtajien" ansiosta, jotka hallitsevat uuden julkaisun tuomista tuotantoon, valvovat seurantaindikaattoreita ja koordinoivat koodia julkaisevien ohjelmoijien työtä.
Jos jotain todella menee pieleen, yritämme havaita ongelman mahdollisimman varhaisessa vaiheessa. Tutkimme ongelman, löydämme virheet aiheuttavan PR:n, peruutamme sen, analysoimme sen perusteellisesti ja luomme uuden koontiversion. Totta, joskus ongelma jää huomaamatta, kunnes projekti menee tuotantoon. Tällaisessa tilanteessa tärkeintä on palvelun palauttaminen. Siksi ennen kuin aloitamme ongelman tutkimisen, palaamme välittömästi edelliseen toimivaan koontiversioon.
Käyttöönottojärjestelmän rakennuspalikoita
Katsotaanpa teknologioita, jotka ovat projektien käyttöönottojärjestelmämme taustalla.
▍Nopeat käyttöönotot
Yllä kuvattu työnkulku saattaa jälkikäteen katsottuna vaikuttaa jokseenkin ilmeiseltä. Mutta käyttöönottojärjestelmästämme ei tullut heti tällaista.
Kun yritys oli paljon pienempi, koko sovelluksemme pystyi toimimaan 10 Amazon EC2 -esiintymässä. Projektin käyttöönotto tässä tilanteessa tarkoitti rsyncin käyttöä kaikkien palvelinten nopeaan synkronointiin. Aiemmin uusi koodi oli vain yhden askeleen päässä tuotannosta, jota edusti lavastusympäristö. Kokoonpanot luotiin ja testattiin tällaisessa ympäristössä, minkä jälkeen ne siirtyivät suoraan tuotantoon. Sellaisen järjestelmän ymmärtäminen oli erittäin helppoa; se antoi kenelle tahansa ohjelmoijalle mahdollisuuden ottaa kirjoittamansa koodi käyttöön milloin tahansa.
Mutta kun asiakkaidemme määrä kasvoi, myös hankkeen tukemiseen tarvittavan infrastruktuurin laajuus kasvoi. Pian järjestelmän jatkuvan kasvun vuoksi käyttöönottomallimme, joka perustuu uuden koodin työntämiseen palvelimille, ei enää tehnyt tehtäväänsä. Nimittäin jokaisen uuden palvelimen lisääminen merkitsi käyttöönoton suorittamiseen tarvittavan ajan pidentämistä. Jopa rsyncin rinnakkaiseen käyttöön perustuvilla strategioilla on tiettyjä rajoituksia.
Päädyimme ratkaisemaan tämän ongelman siirtymällä täysin rinnakkaiseen käyttöönottojärjestelmään, joka oli suunniteltu eri tavalla kuin vanha järjestelmä. Nimittäin nyt emme lähettäneet koodia palvelimille synkronointiskriptin avulla. Nyt jokainen palvelin latasi itsenäisesti uuden kokoonpanon tietäen, että sen oli tehtävä se valvomalla Consul-avaimen muutosta. Palvelimet latasivat koodin rinnakkain. Tämän ansiosta pystyimme ylläpitämään nopeaa käyttöönottoa jopa jatkuvan järjestelmän kasvun ympäristössä.
1. Tuotantopalvelimet valvovat Consul-avainta. 2. Avain muuttuu, tämä kertoo palvelimille, että heidän on aloitettava uuden koodin lataaminen. 3. Palvelimet lataavat tarball-tiedostoja sovelluskoodilla
▍Atomien käyttöönotot
Toinen ratkaisu, joka auttoi meitä saavuttamaan monitasoisen käyttöönottojärjestelmän, oli atomikäyttö.
Ennen atomikäyttöönottoa jokainen käyttöönotto voi johtaa suureen määrään virheilmoituksia. Tosiasia on, että uusien tiedostojen kopiointi tuotantopalvelimille ei ollut ydinprosessi. Tämä johti lyhyeen ajanjaksoon, jolloin uusia toimintoja kutsuva koodi oli saatavilla ennen kuin itse toiminnot olivat käytettävissä. Kun tällainen koodi kutsuttiin, se johti sisäisten virheiden palauttamiseen. Tämä ilmeni epäonnistuneina API-pyyntöinä ja rikkinäisinä verkkosivuina.
Tämän ongelman parissa työskennellyt tiimi ratkaisi sen ottamalla käyttöön "kuumien" ja "kylmien" hakemistojen käsitteet. Hot-hakemiston koodi vastaa tuotantoliikenteen käsittelystä. Ja "kylmissä" hakemistoissa koodia valmistellaan vain järjestelmän ollessa käynnissä. Käyttöönoton aikana uusi koodi kopioidaan käyttämättömään kylmähakemistoon. Sitten, kun palvelimella ei ole aktiivisia prosesseja, suoritetaan välitön hakemistonvaihto.
1. Sovelluskoodin purkaminen "kylmään" hakemistoon. 2. Järjestelmän vaihtaminen "kylmään" hakemistoon, josta tulee "kuuma" (atomitoiminta)
Tulokset: painopiste siirtyi luotettavuuteen
Vuonna 2018 projekti kasvoi niin mittakaavaksi, että erittäin nopea käyttöönotto alkoi haitata tuotteen vakautta. Meillä oli erittäin kehittynyt käyttöönottojärjestelmä, johon panostimme paljon aikaa ja vaivaa. Meidän piti vain rakentaa uudelleen ja parantaa käyttöönottoprosessejamme. Olemme kasvaneet melko suureksi yritykseksi, jonka kehitystyötä on käytetty ympäri maailmaa keskeytymättömän viestinnän järjestämiseen ja tärkeiden ongelmien ratkaisemiseen. Siksi luotettavuudesta tuli huomiomme keskipiste.
Meidän piti tehdä uusien Slackin julkaisujen käyttöönottoprosessista turvallisempi. Tämä tarve sai meidät parantamaan käyttöönottojärjestelmäämme. Itse asiassa keskustelimme tästä parannetusta järjestelmästä edellä. Järjestelmän syvyyksissä käytämme edelleen nopeita ja atomikäyttöisiä teknologioita. Käyttöönoton tapa on muuttunut. Uusi järjestelmämme on suunniteltu ottamaan asteittain käyttöön uutta koodia eri tasoilla, eri ympäristöissä. Käytämme nyt entistä kehittyneempiä tukityökaluja ja järjestelmänvalvontatyökaluja. Tämä antaa meille mahdollisuuden havaita ja korjata virheet kauan ennen kuin ne ehtivät tavoittaa loppukäyttäjän.
Mutta emme aio lopettaa tähän. Kehitämme tätä järjestelmää jatkuvasti käyttämällä kehittyneempiä aputyökaluja ja työautomaatiotyökaluja.
Hyvä lukijat! Kuinka uusien projektijulkaisujen käyttöönottoprosessi toimii siellä, missä työskentelet?
Lähde: will.com