A GitLabnál kétféle módon dolgozzuk fel a szoftverjavításokat: manuálisan és automatikusan. Olvasson tovább, ha többet szeretne megtudni a kiadáskezelő munkájáról, amellyel fontos frissítéseket hoz létre és szállít a gitlab.com automatikus telepítésén keresztül, valamint a felhasználók számára a saját telepítéseik során használható javításokat.
Azt javaslom, állítson be egy emlékeztetőt az okosóráján: minden hónap 22-én a GitLab szolgáltatással dolgozó felhasználók láthatják termékünk aktuális verziójának frissítéseit. A havi kiadás új funkciókat, a meglévők fejlesztéseit tartalmazza, és gyakran megmutatja a közösségi eszközökre vagy egyesítésekre vonatkozó kérések végeredményét.
De amint azt a gyakorlat mutatja, a szoftverfejlesztés ritkán hibamentes. Ha hibát vagy biztonsági rést fedeznek fel, a kézbesítési csapat kiadáskezelője javítást hoz létre felhasználóinknak a telepítéseikkel együtt. A Gitlab.com a CD-feldolgozás során frissül. Ezt a CD-folyamatot automatikus telepítésnek nevezzük, hogy elkerüljük a GitLab CD-funkciójával való összetéveszthetőséget. Ez a folyamat magában foglalhatja a felhasználók, ügyfelek és belső fejlesztői csapatunk által benyújtott lekérési kérelmek javaslatait, így a javítások kiadásának unalmas problémájának megoldása két nagyon különböző módon történik.
«Gondoskodunk arról, hogy a fejlesztők által készített termékek minden nap minden környezetben üzembe kerüljenek, mielőtt közzéteszik a GitLab.com-on.", magyarázza , műszaki vezető, infrastruktúra osztály. "Tekintse meg a telepítéseihez tartozó kiadásokat a gitlab.com-telepítések pillanatképeinek, amelyekhez külön lépéseket adtunk a csomag létrehozásához, hogy a felhasználók telepíthessék azt a telepítéseikre.".
A hibától vagy a sérülékenységtől függetlenül a gitlab.com ügyfelei röviddel a közzététel után megkapják a javításokat, ami az automatizált CD-folyamat egyik előnye. A saját telepítéssel rendelkező felhasználók javításai külön előkészítést igényelnek a kiadáskezelőtől.
A kézbesítő csapat keményen dolgozik a csökkentendő kiadások létrehozásával kapcsolatos legtöbb folyamat automatizálásán (a gyártásig eltöltött átlagos idő, azaz a gyártásra fordított idő), az az időtartam, amely a fejlesztői összevonási kérelem feldolgozásától a gitlab.com webhelyen történő üzembe helyezésig eltelt.
«A szállítócsapat célja, hogy cégként gyorsabban tudjunk haladni, vagy legalább gyorsabban dolgozhassanak a kézbesítők, igaz?, mondja Marin.
A gitlab.com ügyfelei és telepítéseik felhasználói egyaránt profitálnak a kézbesítő csapat azon erőfeszítéseiből, hogy csökkentsék a ciklusidőket és felgyorsítsák a telepítéseket. Ebben a cikkben elmagyarázzuk a két módszer közötti hasonlóságokat és különbségeket. , és azt is leírjuk, hogy kézbesítő csapatunk hogyan készíti elő a javításokat a létesítményeiken dolgozó felhasználók számára, valamint hogyan biztosítjuk, hogy a gitlab.com naprakész legyen az automatikus telepítéssel.
Mit csinál egy kiadáskezelő?
A csapat tagjai havonta a felhasználóknak a létesítményeiken kiadott kiadásaink, beleértve a javításokat és a biztonsági kiadásokat, amelyek a kiadások között előfordulhatnak. Ők felelősek a vállalat automatizált, folyamatos telepítésre való átállásának irányításáért is.
Az öntelepítő kiadások és a gitlab.com kiadások hasonló munkafolyamatokat használnak, de eltérő időpontokban futnak – magyarázza Marin.
A kiadásmenedzser mindenekelőtt a kiadás típusától függetlenül biztosítja, hogy a GitLab elérhető és biztonságos legyen attól a pillanattól kezdve, amikor az alkalmazás elindul a gitlab.com webhelyen, beleértve azt is, hogy ugyanazok a problémák ne kerüljenek az ügyfelek infrastruktúrájába. saját kapacitások.
Ha egy hibát vagy sebezhetőséget javítva jelöltek meg a GitLab-ban, a kiadáskezelőnek értékelnie kell, hogy az belekerül-e a javításokba vagy biztonsági frissítésekbe a felhasználók telepítései során. Ha úgy dönt, hogy egy hiba vagy sérülékenység frissítést érdemel, megkezdődik az előkészítő munka.
A kiadáskezelőnek el kell döntenie, hogy készít-e javítást, vagy mikor telepíti azt – és ez nagymértékben függ a helyzet kontextusától,addig a gépek nem olyan jók a kontextus kezelésében, mint az emberek– mondja Marin.
Minden a javításokról szól
Mik azok a javítások és miért van szükségünk rájuk?
A kiadásmenedzser a hiba súlyossága alapján dönti el, hogy kiadja-e a javítást.
A hibák súlyosságuktól függően változnak. Tehát az S4 vagy S3 hibák stilisztikaiak lehetnek, például pixel- vagy ikoneltolódás. Ez nem kevésbé fontos, de nincs jelentős hatással senki munkafolyamatára, ami azt jelenti, hogy kicsi annak a valószínűsége, hogy az ilyen S3 vagy S4 hibákra javítás készül – magyarázza Marin.
Az S1 vagy S2 biztonsági rések azonban azt jelentik, hogy a felhasználónak nem szabad a legújabb verzióra frissítenie, vagy jelentős hiba van, amely hatással van a felhasználó munkafolyamatára. Ha szerepelnek a nyomkövetőben, sok felhasználó találkozott velük, így a kiadáskezelő azonnal megkezdi a javítás előkészítését.
Miután elkészült az S1 vagy S2 biztonsági rések javítása, a kiadáskezelő megkezdi a javítás kiadását.
Például a GitLab 12.10.1 javítást azután hozták létre, hogy több blokkoló problémát azonosítottak, és a fejlesztők kijavították az ezeket okozó mögöttes problémát. A Release Manager felmérte a hozzárendelt súlyossági szintek helyességét, majd megerősítést követően elindult a javítás kiadásának folyamata, amely a blokkolási problémák felfedezése után XNUMX órán belül elkészült.
Ha sok S4, S3 és S2 halmozódik fel, a kiadáskezelő a kontextust vizsgálja, hogy meghatározza a javítás kiadásának sürgősségét, és amikor elér egy bizonyos számot, akkor mindegyiket egyesíti és felszabadítja. A kiadás utáni javításokat vagy biztonsági frissítéseket a blogbejegyzések foglalják össze.
Hogyan hoz létre javításokat a kiadáskezelő
A javítások generálásához GitLab CI-t és más funkciókat, például a ChatOps-ot használjuk. A kiadáskezelő elindítja a javítás kiadását a ChatOps csapatának belső csatornánkon történő aktiválásával #releases a Slackben.
/chatops run release prepare 12.10.1A ChatOps a Slacken belül működik, hogy különböző eseményeket indítson el, amelyeket aztán a GitLab dolgoz fel és hajt végre. Például a kézbesítő csapat úgy állította be a ChatOps-ot, hogy automatizálja a javítások kiadását.
Miután a kiadáskezelő elindítja a ChatOps csapatot a Slackben, a munka többi része automatikusan megtörténik a GitLabban a CICD használatával. Kétirányú kommunikáció van a Slack ChatOps és a GitLab között a kiadási folyamat során, mivel a kiadáskezelő aktiválja a folyamat néhány fő lépését.
Az alábbi videó a GitLab javításának technikai folyamatát mutatja be.
Hogyan működik az automatikus telepítés a gitlab.com webhelyen
A gitlab.com frissítéséhez használt folyamat és eszközök hasonlóak a javítások létrehozásához használtakhoz. A gitlab.com frissítése kevesebb kézi munkát igényel a kiadáskezelő szemszögéből.
Ahelyett, hogy a ChatOps segítségével futtatnánk a telepítéseket, CI funkciókat használunk, pl. , amellyel a kiadáskezelő ütemezhet bizonyos műveleteket a kívánt időpontban végrehajtandó végrehajtásra. A manuális folyamat helyett van egy óránként rendszeresen lefutó folyamat, amely letölti a GitLab projekteken végrehajtott új módosításokat, csomagolja azokat és ütemezi a telepítést, valamint automatikusan lefutja a tesztelést, a minőségbiztosítást és az egyéb szükséges lépéseket.
„Tehát a gitlab.com előtt sok telepítés fut különböző környezetekben, és miután ezek a környezetek jó állapotban vannak, és a tesztelés jó eredményeket mutat, a kiadáskezelő elindítja a gitlab.com telepítési műveleteit” – mondja Marin.
A gitlab.com frissítéseit támogató CICD technológia automatizálja a teljes folyamatot addig a pontig, amikor a kiadáskezelőnek manuálisan kell elindítania az éles környezet telepítését a gitlab.com webhelyen.
Marin az alábbi videóban részletezi a gitlab.com frissítési folyamatát.
Mit csinál még a kézbesítő csapat?
A fő különbség a gitlab.com frissítési folyamatai és a javítások házon belüli kiadása között az, hogy az utóbbi folyamat több időt és több kézi munkát igényel a kiadáskezelőtől.
„Néha késleltetjük a javítások kiadását az ügyfeleknek a telepítéssel együtt a bejelentett problémák és a szerszámmal kapcsolatos problémák miatt, valamint azért, mert számos árnyalatot kell figyelembe venni egyetlen javítás kiadásakor” – mondja Marin.
A kézbesítő csapat egyik rövid távú célja, hogy csökkentse a kiadáskezelő manuális munkáját a kiadás felgyorsítása érdekében. A csapat azon dolgozik, hogy egyszerűsítse, racionalizálja és automatizálja a kiadási folyamatot, ami segít az alacsony súlyosságú problémák (S3 és S4, kb. fordító). A sebességre való összpontosítás kulcsfontosságú teljesítménymutató: le kell csökkenteni az MTTP-t - az egyesítési kérelem beérkezésétől az eredmény gitlab.com-on történő telepítéséig eltelt időt - a jelenlegi 50 óráról 8 órára.
A kézbesítő csapat a gitlab.com webhely Kubernetes-alapú infrastruktúrára való áttelepítésén is dolgozik.
A szerkesztő n.b.: Ha már hallott a Kubernetes technológiáról (és nem kétlem, hogy hallott), de még nem érintette meg a kezével, javaslom, hogy vegyen részt online intenzív tanfolyamokon , amely szeptember 28-30 között kerül megrendezésre, ill , amelyre október 14–16. Ez lehetővé teszi, hogy magabiztosan navigáljon és dolgozzon a technológiával.
Ez a két megközelítés ugyanazt a célt követi: a frissítések gyors kézbesítése mind a gitlab.com, mind a létesítményeikben lévő ügyfelek számára.
Valami ötlet vagy javaslat a számunkra?
Mindenkit szeretettel várunk, hogy hozzájáruljon a GitLabhoz, és szívesen fogadjuk olvasóink visszajelzéseit. Ha bármilyen ötlete van a szállító csapatunkkal kapcsolatban, ne habozzon értesítéssel team: Delivery.
Forrás: will.com