GitLabissa käsittelemme ohjelmistokorjauksia kahdella tavalla: manuaalisesti ja automaattisesti. Lue eteenpäin saadaksesi lisätietoja julkaisunhallinnan työstä luoda ja toimittaa tärkeitä päivityksiä automaattisen käyttöönoton kautta gitlab.comiin sekä korjaustiedostoja, joita käyttäjät voivat työstää omissa asennuksissaan.
Suosittelen asettamaan muistutuksen älykelloasi: joka kuukausi 22. päivänä GitLabin kanssa työskentelevät käyttäjät voivat nähdä tuotteemme nykyisen version päivitykset. Kuukausittainen julkaisu sisältää uusia ominaisuuksia, olemassa olevien ominaisuuksien kehitystä ja näyttää usein yhteisön työkalujen tai yhdistämispyyntöjen lopputuloksen.
Mutta kuten käytäntö osoittaa, ohjelmistokehitys on harvoin ilman puutteita. Kun virhe tai tietoturvaheikkous havaitaan, toimitustiimin julkaisupäällikkö luo päivityksen käyttäjillemme heidän asennuksiinsa. Gitlab.com päivitetään CD-prosessin aikana. Kutsumme tätä CD-prosessia automaattiseksi käyttöönotoksi, jotta vältetään sekaannukset GitLabin CD-ominaisuuden kanssa. Tämä prosessi voi sisältää ehdotuksia käyttäjien, asiakkaiden ja sisäisen kehitystiimimme lähettämistä vetopyynnöistä, joten korjaustiedostojen julkaisun tylsän ongelman ratkaiseminen ratkaistaan kahdella hyvin eri tavalla.
«Varmistamme, että kaikki kehittäjien tekemä on otettu käyttöön kaikissa ympäristöissä joka päivä ennen kuin se julkaistaan GitLab.comissa", selittää , vanhempi tekninen johtaja, infrastruktuuriosasto. "Ajattele asennustesi julkaisuja gitlab.com-asennusten tilannevedoksina, joihin olemme lisänneet erilliset vaiheet paketin luomiseksi, jotta käyttäjämme voivat asentaa sen asennuksiinsa.'.
Virheestä tai haavoittuvuudesta riippumatta gitlab.comin asiakkaat saavat korjaukset pian niiden julkaisun jälkeen, mikä on automaattisen CD-prosessin etu. Korjaukset käyttäjille, joilla on omat asennuksensa, vaativat erillisen julkaisunhallinnan valmistelun.
Toimitustiimi työskentelee lujasti automatisoidakseen useimpien julkaisujen luomiseen liittyvien prosessien vähentämistä (keskimääräinen aika tuotantoon, eli tuotantoon käytetty aika), aika, joka kuluu kehittäjän yhdistämispyynnön käsittelystä gitlab.com-sivuston käyttöönottoon.
«Jakelutiimin tavoitteena on varmistaa, että pystymme edetä nopeammin yrityksenä tai ainakin saada jakelijat toimimaan nopeammin, oikein?, sanoo Marin.
Sekä gitlab.comin asiakkaat että heidän asennustensa käyttäjät hyötyvät toimitustiimin pyrkimyksistä lyhentää sykliaikoja ja nopeuttaa käyttöönottoa. Tässä artikkelissa selitämme näiden kahden menetelmän yhtäläisyydet ja erot. , ja kuvailemme myös, kuinka toimitustiimimme valmistelee korjauksia käyttäjille, jotka työskentelevät tiloissaan, sekä kuinka varmistamme, että gitlab.com on ajan tasalla automaattisen käyttöönoton avulla.
Mitä julkaisupäällikkö tekee?
Ryhmän jäsenet kuukausittain julkaisumme käyttäjille heidän tiloissaan, mukaan lukien korjaustiedostot ja tietoturvapäivitykset, joita saattaa esiintyä julkaisujen välillä. He ovat myös vastuussa yrityksen siirtymisestä automatisoituun, jatkuvaan käyttöönottoon.
Itseasentuvat julkaisut ja gitlab.com-julkaisut käyttävät samanlaisia työnkulkuja, mutta ne suoritetaan eri aikoina, Marin selittää.
Ensinnäkin julkaisupäällikkö varmistaa julkaisutyypistä riippumatta, että GitLab on saatavilla ja suojattu siitä hetkestä lähtien, kun sovellus käynnistetään gitlab.com-sivustolla, mukaan lukien varmistaa, että samat ongelmat eivät päädy asiakkaiden infrastruktuuriin heidän kanssaan. omia kapasiteettia.
Kun bugi tai haavoittuvuus on merkitty korjatuksi GitLabissa, julkaisun hallinnan on arvioitava, että se sisällytetään käyttäjien korjauksiin tai tietoturvapäivityksiin heidän asennuksissaan. Jos hän päättää, että bugi tai haavoittuvuus ansaitsee päivityksen, valmistelutyö alkaa.
Julkaisupäällikön on päätettävä, valmisteleeko korjaus vai milloin se otetaan käyttöön - ja tämä riippuu suuresti tilanteen kontekstista, "sillä välin koneet eivät osaa hallita kontekstia yhtä hyvin kuin ihmiset" sanoo Marin.
Kaikki on kiinni korjauksista
Mitä laastarit ovat ja miksi tarvitsemme niitä?
Julkaisupäällikkö päättää, julkaistaanko korjaus vian vakavuuden perusteella.
Virheet vaihtelevat niiden vakavuuden mukaan. Joten S4- tai S3-virheet voivat olla tyylikkäitä, kuten pikselin tai kuvakkeen siirtymä. Tämä ei ole yhtä tärkeää, mutta sillä ei ole merkittävää vaikutusta kenenkään työnkulkuun, mikä tarkoittaa, että todennäköisyys, että tällaisiin S3- tai S4-virheisiin luodaan korjaus, on pieni, Marin selittää.
Haavoittuvuudet S1 tai S2 tarkoittavat kuitenkin, että käyttäjän ei pitäisi päivittää uusimpaan versioon, tai siinä on merkittävä virhe, joka vaikuttaa käyttäjän työnkulkuun. Jos ne sisältyvät seurantaohjelmaan, monet käyttäjät ovat kohdanneet ne, joten julkaisunhallinta alkaa välittömästi valmistella korjausta.
Kun haavoittuvuuksien S1 tai S2 korjaustiedosto on valmis, julkaisunhallinta alkaa julkaista korjaustiedostoa.
Esimerkiksi GitLab 12.10.1 -korjaustiedosto luotiin sen jälkeen, kun useita esto-ongelmia tunnistettiin ja kehittäjät korjasivat niitä aiheuttaneen taustalla olevan ongelman. Julkaisupäällikkö arvioi annettujen vakavuustasojen oikeellisuuden ja vahvistuksen jälkeen käynnistettiin korjauksen julkaisuprosessi, joka oli valmis XNUMX tunnin sisällä estoongelmien havaitsemisesta.
Kun S4, S3 ja S2 kerääntyy paljon, julkaisupäällikkö tarkastelee kontekstia määrittääkseen korjauksen julkaisun kiireellisyyden, ja kun tietty määrä niitä saavutetaan, ne kaikki yhdistetään ja vapautetaan. Julkaisun jälkeiset korjaukset tai tietoturvapäivitykset on koottu blogikirjoituksiin.
Kuinka julkaisun hallintaohjelma luo korjaustiedostoja
Käytämme GitLab CI:tä ja muita ominaisuuksia, kuten ChatOpsia, luomaan korjaustiedostoja. Julkaisuhallinta aloittaa korjauksen julkaisemisen aktivoimalla ChatOps-tiimin sisäisellä kanavallamme #releases Slackissa.
/chatops run release prepare 12.10.1ChatOps toimii Slackin sisällä käynnistääkseen erilaisia tapahtumia, jotka GitLab sitten käsittelee ja suorittaa. Toimitustiimi esimerkiksi määritti ChatOpsin automatisoimaan erilaisia asioita korjaustiedostojen julkaisemiseksi.
Kun julkaisupäällikkö käynnistää ChatOps-tiimin Slackissa, muu työ tapahtuu automaattisesti GitLabissa CICD:n avulla. Slackin ChatOpsien ja GitLabin välillä on kaksisuuntainen viestintä julkaisuprosessin aikana, kun julkaisunhallinta aktivoi osan prosessin tärkeimmistä vaiheista.
Alla oleva video näyttää teknisen prosessin korjaustiedoston valmistelussa GitLabille.
Kuinka automaattinen käyttöönotto toimii osoitteessa gitlab.com
Prosessi ja työkalut, joita käytetään gitlab.comin päivittämiseen, ovat samanlaisia kuin korjaustiedostojen luomiseen käytetyt. Gitlab.com-sivuston päivittäminen vaatii vähemmän manuaalista työtä julkaisupäällikön näkökulmasta.
ChatOpsia käyttävien käyttöönottojen sijaan käytämme CI-ominaisuuksia mm. , jolla julkaisupäällikkö voi ajoittaa tiettyjä toimintoja suoritettavaksi vaadittuun aikaan. Manuaalisen prosessin sijaan on olemassa säännöllisesti kerran tunnissa suoritettava putkisto, joka lataa GitLab-projekteihin tehdyt uudet muutokset, pakkaa ne ja ajoittaa käyttöönoton sekä suorittaa automaattisesti testauksen, laadunvarmistuksen ja muut tarpeelliset vaiheet.
"Joten meillä on paljon käyttöönottoja käynnissä eri ympäristöissä ennen gitlab.com-sivustoa, ja kun ympäristöt ovat hyvässä kunnossa ja testaus osoittaa hyviä tuloksia, julkaisupäällikkö aloittaa gitlab.comin käyttöönottotoimenpiteet", Marin sanoo.
Gitlab.com-päivityksiä tukeva CICD-tekniikka automatisoi koko prosessin siihen pisteeseen, että julkaisupäällikön on käynnistettävä tuotantoympäristön käyttöönotto manuaalisesti gitlab.com-sivustolle.
Marin kertoo yksityiskohtaisesti gitlab.comin päivitysprosessista alla olevassa videossa.
Mitä muuta toimitustiimi tekee?
Suurin ero gitlab.com-päivitysprosessien ja korjaustiedostojen julkaisemisen välillä asiakkaille on se, että jälkimmäinen prosessi vaatii enemmän aikaa ja enemmän manuaalista työtä julkaisupäällikköltä.
"Joskus viivyttelemme korjaustiedostojen julkaisemista asiakkaille heidän asennuksissaan raportoitujen ongelmien ja työkaluongelmien vuoksi ja koska yksittäistä korjaustiedostoa julkaistaessa on otettava huomioon monia vivahteita", Marin sanoo.
Yksi toimitustiimin lyhyen aikavälin tavoitteista on vähentää julkaisupäällikön manuaalista työtä julkaisun nopeuttamiseksi. Tiimi pyrkii yksinkertaistamaan, virtaviivaistamaan ja automatisoimaan julkaisuprosessia, mikä auttaa saamaan korjauksia vähävakaisiin ongelmiin (S3 ja S4, noin kääntäjä). Nopeuteen keskittyminen on keskeinen suoritusindikaattori: MTTP:tä - aikaa yhdistämispyynnön vastaanottamisesta gitlab.com-sivustolle tuloksen käyttöönottoon - on lyhennettävä nykyisestä 50 tunnista 8 tuntiin.
Toimitustiimi työskentelee myös gitlab.comin siirtämiseksi Kubernetes-pohjaiseen infrastruktuuriin.
Toimittajan n.b.: Jos olet jo kuullut Kubernetes-teknologiasta (ja en epäile, että olet), mutta et ole vielä koskenut siihen käsilläsi, suosittelen osallistumaan verkko-intensiivikursseille , joka järjestetään 28.-30. ja , joka järjestetään 14.–16. Näin voit navigoida ja työskennellä tekniikan kanssa luottavaisesti.
Nämä ovat kaksi lähestymistapaa, joilla on sama tavoite: nopea päivitysten toimitus sekä gitlab.comille että asiakkaille heidän tiloissaan.
Onko ideoita tai suosituksia meille?
Kaikki ovat tervetulleita osallistumaan GitLabiin, ja otamme mielellämme palautetta lukijoiltamme. Jos sinulla on ideoita toimitustiimillemme, älä epäröi varoituksen kanssa team: Delivery.
Lähde: will.com