Az éjszakai buildelés előnyei

Milyen egy éjszakai build?

Az éjszakai build kifejezést gyakran használják nagy projekteknél. Olyan projektekre gondolok, ahol az elkészült termék teljes rebuildelése túl sok időt venne igénybe ahhoz, hogy minden egyes különálló fejlesztő megcsinálja ezt a feladatot a megszokott fejlesztői ciklusa közben. Ennél fogva, az olyan szoftvert, amely nincs folyamatosan buildelve, bonyolult kiadni – ezért van szüksége a csapatnak az éjszakai buildelésre.

Hogyan építsük meg a Pipeline-t?

Vannak különböző eszközök, amelyek segíteni az éjszakai buildelés infrastruktúrájának a kiépítésével. A legnépszerűbbek a Jenkins és a TeamCity. Nagy segítség, ha rendelkezésünkre áll egy DevOps specialista, aki segít megépíteni a Pipeline-t.

A legfontosabb cél, hogy kitelepítsd a kódot, futtasd egy készletét unit teszteknek, smoke teszteknek, és integrációs teszteknek, ha azok alkalmazhatóak a termékedre és megkapod az eredményeket valamilyen fajta report formájában. Ez az anyag az ügyfél-oldal vagy a menedzsment nézőpontjának – minél színesebb és látványosabb – annál jobb.

Itt egy példája, hogy hogyan lehet felépíteni egy Pipeline-t:

• Az ág HEAD-je ki van véve egy Jenkins slave csomópontra,
• Az ág HEAD-je egy Jenkins slave-re van építve,
• JUnit tesztek futnak,
• Statikus kód analízis fut, melyet minőségbiztosítási kapuk figyelnek,
• Az ág HEAD-je kitelepül egy tesztkörnyezetbe,
• Smoke tesztek futnak a tesztkörnyezet ellen,
• Egy kezdetleges termék születik, mely megjelölésre kerül
• A Jenkinsben lévő buildet megkommentezik a megjelöléssel (amit a kezdetleges termék kapott).

Egy érdekes tényt érdemes itt megemlíteni, miszerint a TestProject program ingyenes tesztautomatizálási platformjával nincs is szükséged egy DevOps specialistára a pipeline-od felépítésére, mivel a TestProject-ben már van egy előre beépített egyszerű Jenkins integrációs felület, vagy használhatod a RESTful API swagger-jét is, hogy egyszerűen elkezdhesd az automatizálás folyamatát.

Miért hasznosak az éjszakai buildelések?

Az éjszakai buildnek meg kell emelnie a verzió számát és mindent el kell látnia a megfelelő verziószámmal. Az a legkényelmesebb lehetőség, ha a rebuild-elő környezet már készen áll másnap reggel, mikor a fejlesztők bejönnek dolgozni. Ekkor tovább folytathatják a munkájukat a legújabb verzióval ott, ahol tegnap abbahagyták.

Az éjszakai buildek emellett azt is biztosítják, hogy a buildelő eszközök nem romlottak-e el a rendszerfrissítések következtében, és emiatt gyakran futtatásra is kerülnek, történjen változás a source kódban, vagy sem. Természetesen, bármikor egy csapat Jenkins-t, vagy bármilyen más eszközt használ buildek futtatására, valakinek felelősnek kell lennie a környezet karbantartásáért és stabilitásáért. Ez trükkös is lehet, különösen a projekt elején. A másik oldalon viszont, ha az éjszakai buildelést később vezetik be, az segít a jobb minőség elérésében és a kód megbízhatóságának fenntartásában.

Az éjszakai buildek a projekt korai fázisaiban rámutathatnak kódolási problémákra. Emellett a kvázi korai-tesztelés és korai-integráció típusú megközelítés mellett az éjszakai build minden nap végén a fejlesztői környezetben végigfut, ami így nemcsak a kód összes változtatását nyomon követi a fejlesztői ágon az adott munkanapon, de emellett tartalmaz minden automatizált egységet, integrációt, és E2E teszteket is.

Az éjszakai build eredményeiből kétféle minőségre vonatkozó állítást is megválaszolhatunk:

• Milyen a már megírt kód minősége?
• Milyen állapotban van a build és a teszt infrastruktúra?

Milyen előnyöket élvez a termék az éjszakai buildelések nyomán?

Néha nem egyszerű meggyőzni a menedzsmentet, hogy érdemes erőforrásokat szánni egy ilyen buildelési befektetésre, még akkor sem, ha a fejlesztők és a tesztelők is élveznék az előnyeit ezeknek a folyamatoknak. Röviden az lesz a menedzsment előnye, hogy könnyedén megállapítható lesz, hogy milyen állapotban van a verzió és kiadható állapotban van-e a termék.

A csapatnak ismernie kell a pipeline kiépítéséhez szükséges erőfeszítések megtérülési értékét. Egy vagy több személynek kell időt belefektetnie és néha karbantartania a rendszert, hogy be lehessen vezetni az éjszakai buildelést.

Emellett, a „probléma” az éjszakai buildekkel az, hogy az előnyei nem láthatóak a menedzsment számára. Viszont, a termék sokat profitálhat a folyamatos releasek-ből, de nem látszik, hogy mennyi munkát kell majd beletenni. Ezek miatt a menedzsmentet néha igen nehéz rávenni arra, hogy pénzt invesztáljanak a CI/CD kiépítésébe, ami számukra kétséges, hogy kifizetődő-e.

Hogyan győzzük meg a menedzsmentet arról, hogy az éjszakai buildekre szükség van?

Az éjszakai buildelés kiépítésének legfőbb előnyei:

• A kód, ami előző napon megírásra került letesztelhető másnap és megmutathatja, ha új problémák kerültek a kód változtatásának nyomán a rendszerbe (a kódba, a tesztekbe vagy az infrastruktúrába), emellett könnyedén beazonosítható mindegyik lehetséges probléma gyökere.
• Minden buildelés egy használható kezdetleges terméket állít elő, amelyet lehet használni – mint release jelöltet – a jövőbeli kitelepítéshez.
• A fejlesztői ágon a kódban lévő hibákat meg lehet találni és ki lehet javítani, még mielőtt más ágakon is hibát okoznának. Mi több, a problémák gyökerének a feltárása sokkal egyszerűbb, ha csak 1 napot kell visszamenőleg átnéznünk, mintha egy egész hetet kellene.
• A buildben, tesztekben, és kitelepítési infrastruktúrában található hibákat korán azonosítani és ennek megfelelően kezelni lehet az új munkanap elején, ami minimalizálja a negatív hatásokat a csapatra nézve.
• A buildelés folyamatos, ezért könnyen össze lehet vetni két vagy több egymás utáni buildet, hogy megkereshessük a problémák gyökerét.
• Az embereknek nem kell emlékeznie a buildelés futtatására, mert az automatikusan megtörténik, ez segít időt spórolni.
• Minden reggel elérhető egy report a kód és a környezet jelenlegi állásáról – ez segít a gyors probléma megoldásban.
• A buildelés éjszaka fut, így nem zavarja a megszokott fejlesztést és kitelepítést, nem foglalja le a környezetet sem.

Az éjszakai buildek segítenek megbizonyosodni abban, hogy a kódbázis egészséges maradt

Az éjszakai buildelések egyik mellékhatása, hogy rákényszeríti a csapatot egy teljesen automatizált build script előállítására és karbantartására. Ez segít a buildelés folyamatának dokumentálásában és a megismételhetőségében.

Mi több, az automatizált buildek jók a következő hibák megtalálásában:

• Valaki átírt valamit, ami tönkreteszi a buildet.
• Valaki elfelejtett egy szükséges fájlt vagy változtatást beküldeni.
• A buildelési script már nem működik.
• A buildelést végző gép elromlott.
• A buildeléshez szükséges program(ok) tanúsítványa lejárt.

Arról vitatkozhatunk, hogy milyen fajta tesztelésre van szükség a szoftveres projektek világában.

Néhány tesztelő és fejlesztő erősen a felfedezések előnyeivel fog érvelni, mások a tesztautomatizálás vagy manuális átnézések hívei. Ettől függetlenül, a modern szoftveres projektekben az éjszakai buildelés egy megkerülhetetlen szükséglet, ha a csapat szeretne a saját kódbázisára számítani és folyamatosan, időről-időre a szoftverüket kitelepíteni. Röviden, megéri az erőforrásokat egy stabil éjszakai buildelési pipeline kiépítése.

Forrás: https://blog.testproject.io/2019/10/14/what-are-the-benefits-of-having-nightly-builds/