A CI/CD pipeline-od lassabb, mint a fejlesztőid

A fejlesztőid gyorsak. Talán túl gyorsak is.

Órák alatt kerül be a kód a repóba, az AI megírja a felét, a pull requestek pedig tornyosulnak. Mégis, az éles környezet három napja változatlan.

Ugye nálatok is csütörtökön van a „release window”?

A probléma nem a fejlesztőkkel van. Hanem a pipeline-nal.

Szállítás nélkül az architektúra csak egy színes ábra

Rengeteget beszélünk az architektúráról: microservices, eseményvezérelt rendszerek, skálázhatóság. De szinte senki nem említi azt az egyetlen tényezőt, ami eldönti, hogy ér-e valamit a rendszered: milyen gyorsan tudsz biztonságosan élesíteni.

Ha nem tudsz gyorsan és megbízhatóan deployolni, az architektúrád nem számít. Akkor az csak egy méregdrága diagram.

A produktivitás illúziója

Az AI felgyorsította a kódolást. Egy REST endpoint, a validáció, a tesztek és a migráció megvan tíz perc alatt. De a gyorsabb kódgenerálás nem jelent gyorsabb szállítást, ha az élesítési folyamat döcög.

Dolgoztam egy projekten, ahol szándékosan nem volt lokális fejlesztői környezet. A csapat úgy döntött: mindenki használjon távoli, felhős környezetet, hogy az összhangban legyen az élessel.

Logikusnak tűnt – amíg nem láttuk a gyakorlatban.

Minden apró módosítást felhőbe kellett deployolni a teszteléshez. Ami lokálisan 30 másodperc lett volna, az a távoli környezetben 15 perc várakozássá nyúlt. A fejlesztő javít egy bugot. Deployol. Vár. Észrevesz egy elütést. Újra deployol. Újra vár.

A javítás csak órákkal később jutott el az éles szerverre. Ez nem hatékonyság, hanem fejlesztői buffering.

Mit jelent valójában a lassú pipeline?

A lassú pipeline nem csak annyit tesz, hogy „húsz percig fut a CI”. Gyakran semmi köze a technikai folyamathoz.

Egy másik projekten rendszeres release meetingeket tartottak. Minden kiadás előtt leültünk átnézni a jegyeket: mi megy ki, mi van a csomagban, kit kell értesíteni. Standard procedúra.

Egyszer húsz percet vitatkoztunk a listáról, mire kiderült: a release egyetlen frontend módosítást tartalmaz. Egyetlen szóközt egy feliratban.

A másik két változtatás, amit szintén ki akartunk tenni, már korábban kiment, csak senki nem jelölte őket releaseben, így nem szerepeltek a nyilvántartásban. Maradt tehát a „csomagban” egy egykarakteres javítás.

Húszperces meeting kellett hozzá.

Ha folyamatosan szállítanánk, nem lenne mit egyeztetni. Nem a meetinggel volt a baj, hanem a batch-eléssel.

A sebesség architektúra kérdése

A legtöbb csapat a CI/CD-re eszközként tekint: „pár Jenkins job, néhány GitHub runner”. Pedig ez is a szoftverarchitektúra része.

Láttam ezt közelről: egy csapat korán szétválasztotta a repókat a tiszta határok és a független felelősségi körök miatt. Jó ötletnek tűnt.

Csakhogy senki nem számolt a repók közötti függőségekkel. A munkafolyamatok egymásra épültek, de nem voltak contract tesztek. Ezek nélkül a frontend és a backend rendszeresen „eltörte” egymást – nem a rossz kód miatt, hanem mert nem volt automatikus jelzés, ha az egyik oldal módosított valamin, amire a másik támaszkodott.

Minden deploy szerencsejátékká vált. A pipeline nem a rossz eszközök miatt volt lassú, hanem mert az architektúra ellehetetlenítette a független telepítést.

A lassú szállítás ára

A lassú folyamatok nemcsak időt égetnek, hanem a fejlesztők hozzáállását is rontják.

Ugyanazon a projekten három code owner jutott negyven fej.esztőre. Minden PR rajtuk ment keresztül. A review-k hetekig elhúzódtak. A fejlesztők ezért elkezdtek „csomagolni”.

„Miért nyissak három külön PR-t és várjak háromszor hetekig, ha egyben is letudhatom?”

Az eredmény: hatalmas PR-ok, átláthatatlan review-k, óriási kockázat. Ha pedig valami elromlott, senki nem tudta, melyik módosítás okozta. Aztán jött a „megoldás”: éjszakai deploy, „hátha így nem lesz baj”.

Gratulálok: a telepítést sikerült egy stresszes eseménnyé tenni. Pedig a deploynak a napi rutin részének kellene lennie.

Milyen a valóban gyors folyamat?

A gyors pipeline nem a nyers sebességről, hanem a bizalomról szól.

A fejlesztő végez egy apró módosítást, beküldi, és tíz perc múlva élesben látja. Nincs dráma. Ha bug kerül ki, a rollback harminc másodperc. Nincs meeting, nincs pánik. Az új funkciók feature flag mögött mennek ki, és akkor aktiválódnak, amikor készen állnak.

Tagolt. Unalmas. Kiszámítható.

Ez a cél. Mert ha a deploy izgalmas, ott valami nagyon el van rontva.

Hogyan javítsd meg – vállalati processek nélkül?

A lassú pipeline-t nem újabb eszközökkel és még bonyolultabb folyamatokkal javítod meg, hanem egyszerűsítéssel.

Napi egy nagy PR helyett: tíz kicsi.
Közös adatbázis-módosítások helyett: visszafelé kompatibilis migrációk.
Manuális QA helyett: megbízható automatizált tesztek.
Release meetingek helyett: folyamatos szállítás (CD).

Minden manuális jóváhagyás csak egy tünet. Minden bizonytalan teszt technical debt. Minden „hátha így jó lesz” szabály csak a félelem, amit folyamatnak álcáztak.

Az igazi kérdés

Az AI tovább gyorsítja a fejlesztőket. Ez a tempó már nem fog lassulni.

A kérdés az: a szervezeted bírja-e ezt az iramot? Mert ha a pipeline lassabb a fejlesztőknél, akkor épp azt a folyamatot fojtod meg, ami a bevételt termeli: a delivery-t.

Ha CTO vagy vezető mérnök vagy, és érzed, hogy a csapatod csak „pufferezik” a tényleges szállítás helyett, tegyünk ellene.

Segítek tech cégeknek áthidalni a szakadékot a fejlesztői munka és az üzleti érték között. Feltérképezzük a szűk keresztmetszeteket – legyen szó kódról, architektúráról vagy döntéshozatali folyamatokról –, és felépítünk egy hatékonyabb utat az éles környezet felé.

Beszéljünk, és nézzük meg, hogyan tehetjük gördülékenyebbé a folyamataitokat!