Egy ág, egy gomb.
Javaslat a HTTP Alapítvány kiadási folyamatára: 27 repó, egy közös út a commit és az éles szerver között.
feat/xmain2026. november · Fejlesztői csapat · Továbblépés: → vagy húzás
Ma egy kiadás két kézi tag és két külön build
- Mindkét tag ugyanarra a commitra mutat. A legutóbbi kiadásnál 11 másodperc telt el köztük.
- A
-ttaget a release.httpf.hu nem tudja létrehozni, mert a verzióellenőrzése elutasítja. - A build csak a tag után fut le, így a hibás build elhasznál egy verziószámot: május óta 125 futásból 15 bukott el.
Forrás: deploy.yml, http-release forráskód, Actions-futások 27 repóban (2026. máj. 1-től).
A teszt legtöbbször nem előzi meg az élest
9 / 15
éles deploy úgy indult, hogy ugyanennek a commitnak a teszt deployja még nem ért véget, vagy nem is volt.
Korábbi commitokat sokszor teszteltünk. Ez azt méri, hogy pontosan a kiadott commit végigfutott-e a teszten.
2 Nem volt teszt
7 Éles a teszt vége előtt
3 10 percen belül a teszt után
3 Később
Forrás: GitHub Actions futási idők, 5 repó, az adott repó első -t futásától 2026. nov. 7-ig. Csak azonos commiton futó teszt számít.
Ugyanaz a commit, két különböző image
| Repó és verzió | Commit | Teszt digest | Éles digest |
|---|---|---|---|
| http-cms-admin v0.1.25 | c93916d | 7911ad8a1380 | c89056fbeea8 |
| http-cms-admin v0.1.24 | a519538 | 27d76ae444e3 | 9c068b2e91db |
| http-cms-admin v0.1.23 | 855d64b | 24310c2a4ff7 | 67a5a2746efe |
| http-cms-admin v0.1.22 | ac3a9e9 | e963a8353106 | 684722d6d79b |
| http-cms-admin v0.1.21 | 26cc8c6 | de57c6ad4f66 | 043a5bd74c18 |
| http-image-editor v1.0.1 | e905e3d | 0eb6749c6a80 | 1c8d1aee36f7 |
| http-image-editor v1.0.0 | b05eb7f | e190e2790cd6 | ba5c9f2d0467 |
| szakmavilag v1.0.12 | 1a36383 | f84b79c48b9c | 7b159e2bcebf |
8 / 8
összevetett kiadásnál eltért a digest, tehát amit teszteltünk, nem bájtra ugyanaz, ami kimegy.
Ez önmagában nem jelent eltérő működést. De 26 Dockerfile-ból 11 nem rögzíti a csomagkezelő verzióját, és 3 frissülő rendszercsomagokkal épül, ezért az egyezést garantálni sem tudjuk.
Forrás: a docker push által naplózott digestek az Actions-logokban (első 12 karakter); a repók Dockerfile-jai.
A zöld pipa nem jelenti, hogy kikerült
v0.1.22 · success{"success":true,
"image":"…/http-cms-admin:latest",
"total":3,"successful":2,"failed":1}
v0.1.5 · success{"success":true,
"image":"…/szakma-sztar:latest",
"total":0,"successful":0,"failed":0}
24 / 75
friss zöld futásnál hibázott egy konténer (11), vagy nem frissült semmi (13).
A Pulldeck ilyenkor is success:true választ ad, a deploy action pedig az összes hibát elnyeli: curl -f … || echo "Warning".
Okt. 28. után már nincs ilyen, és a 11 hibát ugyanaz az elárvult test-wshu-admin konténer okozta. A következő esetet viszont ugyanígy nem venné észre semmi.
Forrás: 14 repó legutóbbi zöld, tag által indított futásainak Pulldeck-válaszai az Actions-logokból (2026. nov. 7.); pulldeck forráskód.
27 repó, 17 féle deploy workflow
Egy csoport egy workflow-változat. A repónév, a kommentek és a whitespace nem számít különbségnek.
repóban kellett kézzel, ugyanazon a napon (okt. 28.) megcsinálni ugyanazt a Pulldeck-javítást
repó cache-eli a /var/lib/docker mappát; a 3 ellenőrzött futásból mindhárom Cache not found
repó használ v4-nél régebbi actions/checkout verziót
deploy workflow futtat lintet vagy tesztet a build előtt
Forrás: a release.httpf.hu repólistája és további aktív repók workflow-fájljai, 2026. nov. 7.
A csapat már most ezt csinálja: pushol, és nézi a teszten
Egyetlen tag 3 hét alatt 11 commitra került át, köztük egy még nem merge-elt feature branchre. Összesen 6 tagnév mozgott így. Az igény valós: a teszt kövessen egy ágat.
Forrás: wshu-training-app Actions-futások, okt. 15. – nov. 5.; a tagek áthelyezése 4 repó futásaiból.
Az első javaslat: development a tesztre, main az élesre
Vészhelyzetben lehet közvetlenül commitolni a védett main-re.
Ami ebből jó irány
- A teszt automatikusan követ egy ágat
- Az éles védett, de vészhelyzetben elérhető
- Nem lesz minden pushból új verzió
- Minden commit visszakereshető marad
Ezek a célok maradnak. Egy ponton akad el: a két ág közötti squashnál.
A squash elválasztja a két ágat
A development két commitja várja a kiadást.
$ git log --oneline --graph --all
* 1393c18 feat: nagyobb limit
* bc0b8e8 feat: új cím
* 784dd40 init
Squash után a main új commitot kap, ami nem leszármazottja a development commitjainak.
$ git log --oneline --graph --all * 1393c18 feat: nagyobb limit * bc0b8e8 feat: új cím | * 3538eb2 release 1 (squash) |/ * 784dd40 init
A munka megy tovább, és valaki ugyanazt a sort javítja.
$ git log --oneline --graph --all * 0ee845f fix: cím javítása * 1393c18 feat: nagyobb limit * bc0b8e8 feat: új cím | * 3538eb2 release 1 (squash) |/ * 784dd40 init
A második kiadás PR-je újra felsorolja a már kiadott commitokat, és ütközik.
$ git log --oneline main..development 0ee845f fix: cím javítása 1393c18 feat: nagyobb limit bc0b8e8 feat: új cím $ git merge --squash development Auto-merging app.yml CONFLICT (content): Merge conflict in app.yml Automatic merge failed; fix conflicts and then commit the result.
Elkerülhető, ha minden kiadás után visszamerge-eljük a main-t. Ez minden kiadásnál plusz lépés, 27 repóban.
Ugyanez a munka egy ágon: nincs mit szinkronban tartani, és a történet feature-önként egy commit.
$ git merge --squash fix/cim Fast-forward app.yml | 2 +- $ git log --oneline main 361dec5 fix: cím javítása (#2) de068fb feat: új cím és nagyobb limit (#1) 784dd40 init
Valódi git-kimenet egy helyi próbarepóból, rövidítve.
A második ág itt kevés haszonért folyamatos gondozást kér
aktív repónak egy szerzője volt 90 nap alatt, ezért alig van mit egy közös ágon összefésülni
appnak van élő teszt környezete, a többi repóban a development nem deployolna sehova
commit a lemaradása a wshu-training-app dev ágának, a staging-é 79. Egyiken sincs commit 2024 óta
A napi munka ugyanaz
Feature ág, vagy kis javításnál közvetlen commit, majd automatikus teszt. A különbség annyi, hogy mi jelöli az élest: egy ág vagy a legutóbbi tag.
Működő alternatíva: development + fast-forward
Akkor jobb, ha fontos, hogy a main mindig az éles legyen, vagy külön release-jóváhagyást szeretnénk. Ára: új alapértelmezett ág, release tool módosítás, és a hotfixek visszamerge-elése.
Forrás: GitHub API, 27 repó, 90 nap (2026. aug. 9. – nov. 7.); futó konténerek a teszt szerveren.
Az ajánlott folyamat: egy ág, egy gomb, egy image
feat/xmainMunka az ágon
Nagyobb munka ágon és PR-ben készül, squash merge-dzsel. Egy-két commitos javítás mehet közvetlenül a main-re, mert a push csak a tesztig jut.
$ git switch -c feat/uj-urlap $ git push -u origin feat/uj-urlap # deploy nincs, CI lefut
Push a main-re
A CI itt is lefut. Ha hibás, a folyamat megáll, és a tesztig sem jut el. Minden commit megmarad a PR-en és a squash commit szövegében.
lint, type-check, test # ami a repóban elérhető
Egyetlen build
Az image a commitról kapja a nevét. Nincs git tag és nincs release, ezért a pushok nem töltik tele a kiadások listáját.
ghcr.io/…/app:sha-abc123 ghcr.io/…/app:test # az appban látható verzió: # git describe → v1.0.10-5-gabc123
Automatikus tesztdeploy
A Pulldeck frissíti a tesztet, újabb push a régebbi buildet megszakítja. Teszt környezet nélküli repóban ez a lépés kimarad, minden más ugyanaz.
# befejezetlen feature tesztre: Actions → Deploy to test → Run workflow # a következő main push felülírja
Egy gomb
A release.httpf.hu ugyanúgy létrehozza a verziótaget, mint ma. A toolon nem kell kódot változtatni, a -t tagek pedig megszűnnek.
release.httpf.hu → Release # tag: v1.0.11 # csak a kijelölt csapat hozhat létre v* taget
Ugyanaz az image megy ki
Nincs új build. A workflow megvárja a commit image-ét, átcímkézi, és meghívja a Pulldecket. A job piros, ha egy konténer hibázik, vagy nem frissült semmi.
$ crane tag …/app:sha-abc123 v1.0.11 $ crane tag …/app:sha-abc123 latest $ pulldeck deploy fail if failed > 0 or total = 0
Az első javaslat céljai mind megmaradnak
| Cél | Hogyan teljesül |
|---|---|
| Ne menjen ki semmi véletlenül élesre | A push csak a tesztig jut. v* taget ruleset alapján csak a kijelölt csapat hozhat létre. |
| Vészhelyzetben lehessen gyorsan javítani | Közvetlen commit a main-re, majd Release. A szabályok megkerülése naplózott, a force push tiltott marad. |
| A teszt magától frissüljön | Minden main push automatikusan tesztre megy, branch pedig kérésre. |
| Ne teljenek meg a release-ek | Csak az éles kap verziót. Az elmúlt 90 napban 64 helyett 41 release lett volna. |
| Tiszta történet | Feature-önként egy commit a main-en, kiadásonként egy tag. |
| Minden commit visszakövethető | A PR megőrzi az összes commitot, a squash commit szövege pedig felsorolja őket. |
GitHub Team csomagon, privát repóban nincs kötelező jóváhagyó és várakozási idő az environmenteknél, ezért a kapu a tagre vonatkozó ruleset és a Release gomb. A kötelező review 13 egyszerzős repóban amúgy is megakasztaná a munkát.
Forrás: GitHub dokumentáció (deployment environments, rulesets), GitHub Changelog 2025. jún. 16.; GitHub API.
Mi történik, ha nem a tervek szerint alakul?
A befejezetlen munka az ágán marad
- Csak a kész munka kerül a
main-re. - A befejezetlen feature a saját ágán, a Run workflow gombbal mehet tesztre.
- Ha A és B is a
main-en van, de csak A jó, B-t revertáljuk a kiadás előtt.
Revert, vagy új ág a tagből
- Ha lehet, a kiadatlan commitot revertáljuk, és a szokásos úton megyünk.
- Ha nem, új ágat nyitunk az utolsó tagből, és arról adunk ki.
- Ehhez a commithoz még nincs image, ezért a workflow most egyszer buildel.
- A javítást visszavisszük a
main-re.
Rollback a régi image-re, build nélkül
- Actions → Rollback → az előző verzió kiválasztása.
- Az előző image újra megkapja a
:latesttaget. - A Pulldeck frissít. Ez a lépés mérten 10–23 másodperc.
Az adatbázis nem áll vissza. Ha az új verzió migrált, a rollback előtt ellenőrizni kell, hogy a régi kód működik-e az új sémával.
Először a teszten kell kibuknia
- A backend indításkor futtatja a
prisma migrate deployparancsot, tehát a teszten is lefut. - Nov. 4-én így bukott ki egy migráció a teszten: P3009, 10 újraindítás, az éles érintetlen maradt.
- A sémaváltozást a rá épülő kódtól külön, visszafelé kompatibilisen adjuk ki.
A Pulldeck a konténer elindulását jelzi, nem azt, hogy egészséges. A közös workflow-nak a healthcheckre is várnia kell.
Commit a main-re, majd Release
- A
main-re PR nélkül is lehet pushni, tehát nem kell semmit megkerülni. - A push lefuttatja a CI-t és a tesztdeployt.
- Release gomb. Ha a CI-t is meg kell kerülni, azt csak kijelölt admin teheti, naplózva.
A migrációs példa forrása: a mkik-http-cms-backend-test konténer naplója. A Rollback és a Deploy to test még megépítendő workflow.
Kiadásonként egy kattintás és egy build
| Kiadásonként | Ma | Javaslat |
|---|---|---|
| Kézi lépés | 2 tag | 1 Release gomb |
| Build | 2 | 1 |
| Tesztre kerülés | kézi tag után | minden push után, magától |
| Teszt és éles image | eltérő (8 / 8) | ugyanaz |
| Kattintástól élesig | kb. 166 mp (medián) | kb. 30 mp (becslés) |
| Rollback | kézzel | kb. 30 mp (becslés) |
| Hibás deploy | zöld job | piros job |
| Release-ek 90 nap alatt | 64 | 41 |
A 166 mp 254 sikeres tag-futás mediánja. A 30 mp a mért 10–23 mp-es Pulldeck-lépés és az átcímkézés becsült összege; a pilot méri majd pontosan.
Négy dolgot előbb rendbe kell tenni
Teszt szerver
t3.micro, kb. 220 MiB szabad memória, 91%-os lemez, és nincs rajta prune cron, ami az élesen van. 15,57 GB felszabadítható. Egy wshu-training-app deploy 2,5 GB-ot hagy maga után. Élő teszt környezete 5 appnak van.
Prune cron most, méret a bevont appok szerint
S3 és levelezés
A teszt és az éles ugyanazt az S3 bucketet és hozzáférési kulcsot használja, és ugyanazon a mail hoston küld. Az adatbázis külön van. A teszten feltöltött fájl az éles bucketbe kerül. Törlő S3-hívást nem találtunk a backendben.
Külön teszt bucket és tesztes levelezés
Backend image
Élesen a http-backend és a backend image fut, a teszten a http-cms-backend. A backend tesztje így még nem azt próbálja, ami élesen megy.
Az éles átállítása külön lépés
Deploy visszajelzés
A pulldeck-deploy-action ma elnyeli a hibákat. Egyetlen commit a @v1 tagen mind a 25 repót javítja, függetlenül attól, melyik folyamatot választjuk.
Piros job, ha failed > 0 vagy total = 0
Forrás: a két szerver állapota 2026. nov. 7-én (csak olvasás), a aws2-infra repó és a http-cms-backend forráskódja.
Bevezetés lépésekben, négy közös döntéssel
1. Most
Deploy action javítása és prune cron a teszt szerveren. Bármelyik folyamatnál hasznos.
2. Pilot
Közös workflow repó és ruleset, először a http-cms-admin repón. Itt mérjük a tényleges időket.
3. Aktív repók
A többi repó, ahol van teszt környezet, utána aki sokat ad ki.
4. A többi
Amikor legközelebb hozzányúlunk. 10 repóban 90 napja nem volt commit, azokat addig nem bántjuk.
Amit ma el kell dönteni
- 1Elfogadjuk az egyágas folyamatot?
- 2Mely appoknak kell teszt környezet, és kell-e nagyobb szerver?
- 3Mikor választjuk külön a teszt S3-at és levelezést?
- 4Ki indíthat release-t?