Telepítési idő csökkentése 80%-kal

Fintech startup · GitOps · ArgoCD · Multi-környezet automatizálás

A kihívás

Egy gyorsan növekvő fintech startup eljutott arra a pontra, ahol a régi telepítési rutin már nem bírta a tempót. A fejlesztőcsapat egy év alatt 5 főről 25-re nőtt, a release folyamat viszont maradt a régi: SSH a szerverre, friss kód lehúzása, migrációk futtatása, aztán csendes reménykedés, hogy most épp minden rendben lesz. Ismerős helyzet.

A problémák egyre súlyosabbak lettek:

  • A telepítések 45+ percig tartottak, és egy senior mérnök teljes fókuszát elvitték
  • A négy környezet (dev, staging, QA, production) folyamatosan eltért egymástól. A „stagingen működik” mondat már inkább fáradt sóhaj volt, nem poén
  • Nem volt rollback stratégia. Ha productionben valami elromlott, indulhatott az azonnali tűzoltás
  • A release gyakoriság heti szintre esett vissza, mert mindenki kerülte a procedúrát, amennyire lehetett

Világos volt, hogy gyorsabban kell szállítani, de úgy, hogy közben ne legyen gyomorgörcs minden kiadás előtt.

A megközelítés

Egy teljes GitOps átállást javasoltam ArgoCD-re és ApplicationSets-re építve. Ezt a megközelítést több projekten csiszoltam, és itt is jól működött.

1. fázis: Alapozás (1-2. hét)

Első lépésként rendbe tettem a konténeres alapokat. A fejlesztői gépeken már futott Dockerben az app, productionben viszont még systemd-s foltozgatás ment. Multi-stage Docker buildre álltunk át distroless base image-ekkel, amivel kb. 60%-kal csökkent az image-ek mérete.

Minden Kubernetes manifest külön, dedikált GitOps repóba került, az alkalmazáskódtól elválasztva. Ezt a mintát kifejezetten ajánlom: az alkalmazás repója mondja meg, mit buildelünk, a GitOps repó pedig azt, hol és hogyan fut.

2. fázis: ArgoCD ApplicationSets (2-3. hét)

Itt kezdett igazán összeállni a rendszer. Ahelyett, hogy minden környezethez külön ArgoCD Applicationt gyártottunk volna, ApplicationSetet használtam git generátorral. Egy sablon, négy környezet:

  • Minden környezet saját könyvtárat kapott Kustomize overlayekkel
  • A környezetfüggő értékek (replikák, erőforráslimitek, feature flagek) egyszerű YAML fájlokba kerültek
  • Egy release stagingről productionbe történő előléptetése egyetlen pull request lett

Az ApplicationSet minta nagy előnye később jött ki igazán: amikor egy új compliance elvárás miatt be kellett hozni egy ötödik környezetet, ez kb. 10 perc volt, nem egy egyhetes projekt.

3. fázis: Pipeline integráció (3-4. hét)

A GitHub Actionst szorosan rákötöttem a folyamatra:

  1. PR merge main-be → konténer image build és push
  2. Image tag automatikus frissítése a GitOps repóban (dev környezet)
  3. Dev telepítés automatikusan ArgoCD sync-kel
  4. Staging/production előléptetés PR-rel, automatizált ellenőrzésekkel

Innentől minden telepítés egy git commit lett. Minden rollback egy git revert. Végre visszakövethető volt, hogy mi, hol és mikor futott.

Az eredmények

Négy hét implementáció és egy hét párhuzamos futás után ezt láttuk:

80%-kal gyorsabb

A telepítési idő 45+ percről 8 perc alá csökkent, az összes automatizált ellenőrzéssel együtt.

4x release gyakoriság

Heti kiadásokról napi többszöri telepítésre váltottunk. A csapat akkor szállított, amikor készen állt, nem akkor, amikor a naptár engedte.

Nulla eltérés

Mind a négy környezet kódban definiálva. Nincs több „stagingen működik”, mert a staging és a production strukturálisan azonos lett.

A legnagyobb nyereség végül nem is technikai, hanem kulturális volt. A junior fejlesztők elkezdték önállóan telepíteni a saját feature-jeiket. Az ügyeleti rotáció kezelhetőbb lett, mert egy rollback nagyjából 30 másodperces git revertre egyszerűsödött. A csapat elengedte a release előtti stresszt, és ténylegesen átállt continuous deliveryre.

„Pénteken már nem izgulunk, pénteken telepítünk. Ennél jobb visszajelzés nem is kell.” - Engineering Lead

Beszéljünk? Segítek kitalálni, mire van szükséged.

Ingyenes Konzultáció