7.6 Környezetek: local, staging, production – és miért különböznek

Áttekintő

„Nálam működik." Ez az a mondat, amit minden fejlesztő kimondott már legalább egyszer – és ami a legtöbb csapatban azonnali szemforgatást vált ki. Mert ha nálad működik, de a staging-en vagy production-ban nem, az azt jelenti, hogy a két környezet nem egyforma. És az esetek nagy részében ezt elkerülhető lett volna.

A modern szoftverfejlesztésben a kód legalább háromféle környezetben fut, mielőtt eljut a valódi felhasználókhoz: a saját gépeden (local), egy teszt szerveren (staging), és végül élesben (production). E három környezet célja, struktúrája és konfigurációja szándékosan különbözik egymástól – és ha ezt nem érted, sok felesleges hibát fogsz debuggolni.

Ebben az alfejezetben megérted, miért léteznek ezek a rétegek, mi lehet köztük a különbség, és hogyan kerülheted el a leggyakoribb környezetből fakadó hibákat.

Részletes leírás

A három alapkörnyezet

Local (helyi fejlesztői környezet)

Ez a te saját gépeden fut. Csak te látod, csak te használod. Szabadon kísérletezhetsz, törölhetsz, újraindíthatsz – nincs következménye. Az adatbázisban teszt adatok vannak (vagy üres az egész), az API kulcsok sandbox módban működnek, a logolás részletes, a hibák teljes stack trace-szel jelennek meg.

Célja: gyors fejlesztés és iteráció.

Staging (tesztkörnyezet, UAT, pre-production)

Ez egy szerveren fut, de nem éles forgalommal. Ide kerül a kód, mielőtt production-ba kerülne. A staging környezet ideális esetben minél jobban hasonlít a production-ra – ugyanolyan szerver, ugyanolyan adatbázis-motor, ugyanolyan konfiguráció, de tesztelési adatokkal.

Célja: ellenőrizni, hogy a kód a valódi szerver környezetben is működik, mielőtt a valódi felhasználók látják.

Production (éles környezet)

Ez az, ahol a valódi felhasználók vannak. Hibák itt már következményekkel járnak: elégedetlen ügyfelek, adatvesztés, bevételkiesés. Production-ban szigorúbb a konfiguráció: nincs részletes hibaüzenet a felhasználónak, a logolás szintje alacsonyabb (nincs DEBUG), az adatbázis valódi adatokat tartalmaz.

Célja: megbízhatóan, biztonságosan és hatékonyan kiszolgálni a felhasználókat.

Mi lehet különböző a környezetek között?

Ez az a lista, amit érdemes fejből tudni, mert ezek a leggyakoribb okai az „nálam működik, ott meg nem" problémáknak:

1. Adatbázis

Szempont	Local	Staging	Production
Adat	Tesztelési / fejlesztői adat	Anonimizált teszt adat	Valódi adatok
Méret	Kicsi	Közepes	Lehet nagyon nagy
Szerver	Helyi gép	Szerver	Szerver (más lehet)

Egy hiba: lokálisan 100 sorral tesztelted az SQL lekérdezést, production-ban 10 millió sor van – és hirtelen timeout-olni kezd minden. Lokálisan nem jelentkezett.

2. Környezeti változók (environment variables)

Ez a leggyakoribb különbség. A kódod nem tartalmaz hardcoded konfigurációs értékeket – hanem környezeti változókból olvassa ki. Ezek lehetnek:

Adatbázis kapcsolati adatok (DB_HOST, DB_PASSWORD)
Külső szolgáltatások API kulcsai (STRIPE_SECRET_KEY, SENDGRID_API_KEY)
Az alkalmazás alap URL-je (APP_URL)
Debug mód (APP_DEBUG=true / false)
Logolás szintje (LOG_LEVEL=debug / error)

Lokálisan ezek .env fájlban vannak. Staging-en és production-on a szerver konfigurációjában vannak beállítva (soha nem kerülnek verziókövető rendszerbe!).

Egy hiba: lokálisan a Stripe sandbox kulccsal tesztelsz, production-ban az éles kulcs van beállítva. Ha felcseréled, vagy ha valamelyik kulcs hiányzik, a fizetési folyamat elromlik.

3. Külső API-k és sandbox módok

A legtöbb külső szolgáltatás (fizetési rendszer, e-mail küldő, SMS gateway) kétféle módban létezik:

Sandbox / test mód: semmilyen valódi tranzakció nem történik, ingyenes, fejlesztésre való
Éles mód: valódi tranzakciók, valódi pénz, valódi e-mailek

Ha lokálisan a sandbox kulccsal tesztelsz, de a kód production-ba kerül, és az éles kulcs nincs megfelelően beállítva – akkor vagy nem működik, vagy rosszabb esetben valódi tranzakciók indulnak el tesztelés közben.

4. Logolás szintje

Lokálisan szívesen látod a részletes DEBUG logokat – minden SQL lekérdezést, minden függvényhívást. Production-ban ez:

Lassítja az alkalmazást (minden log I/O művelet)
Tömérdek szenzitív adatot naplózhat (pl. jelszavak, tokenek, SQL lekérdezések)

Ezért production-ban általában csak WARNING és ERROR szintű logokat érdemes hagyni.

5. Fájl elérési utak és engedélyek

Lokálisan a fejlesztő gépen minden mappa elérhető. Szerveren előfordulhat, hogy a feltöltött fájlok mappájának nincs írási jogosultsága az alkalmazásnak, vagy a könyvtárstruktúra más.

6. Szerveres erőforrások és korlátok

A szerver más PHP memória limitet, más request timeout értéket, más fájlméret limitet engedélyezhet. Ami lokálisan megy 30 másodperc alatt, az production-ban timeout-olhat, mert ott 10 másodperc a limit.

A „works on my machine" probléma gyökere

A probléma oka mindig az, hogy valami különbözik a két környezet között – és ezt nem vetted figyelembe.

A leggyakoribb okok:

Különböző szoftververziók – lokálisan Python 3.11, szerveren Python 3.9. Vagy Node 20, szerveren Node 16. Szintaxis és API különbségek léphetnek fel.

Hiányzó vagy eltérő környezeti változók – staging-en nincs beállítva az API_KEY, amit lokálisan a .env-ből olvas.

Fájlrendszer különbségek – Windows / macOS vs. Linux fájlnév case-sensitivity. Lokálisan MyFile.js és myfile.js ugyanaz. Linux szerveren nem.

Lokálisan nincs tesztelve az inicializáció – a fejlesztő gépén már fut az adatbázis és minden service. Szerveren a service-ek indítási sorrendje és késleltetése más lehet.

Hardcoded lokális útvonal – a kódban /Users/peter/projects/myapp/uploads szerepel egy feltöltési mappanévként. Szerveren ez az útvonal nem létezik.

A megoldás nem varázslat: a staging minél jobban hasonlítson a production-ra, a különbségek konfigurációban legyenek (nem a kódban), és minden környezetspecifikus adat környezeti változóból jöjjön.

Deployment folyamat nagyvonalakban

A kód útja a fejlesztői gépről a production-ig általában így néz ki:

1. Local fejlesztés
   └─► git commit + push a feature branch-re

2. Code review + tesztek futtatása (CI pipeline)
   └─► automatikus tesztek zöldek? ✓

3. Merge a fő branchbe (main / master / develop)
   └─► automatikusan deploy a staging-re

4. Tesztelés staging-en
   └─► manuális QA, PO/PM jóváhagyás

5. Deploy production-ba
   └─► manuális trigger VAGY automatikus (ha minden OK)

Ez az egyszerűsített GitOps / CI-CD flow. Junior fejlesztőként valószínűleg az 1-2. lépésnél fogsz aktívan részt venni. A 3-5. lépéseket általában automatizált rendszerek kezelik (GitHub Actions, GitLab CI, Jenkins stb.).

A lényeg: a kód nem kerül közvetlenül production-ba – mindig van legalább egy közbülső lépés.

Miért kell a staging?

Néhány valós ok, amit a staging mentett meg:

Az adatbázis migráció lokálisan lefutott 2 másodperc alatt, staging-en 45 percig tartott (mert production méretű adat volt), és közben az applikáció használhatatlan volt.
Az e-mail küldés lokálisan működött, staging-en nem – mert a szerver tűzfala blokkolta az SMTP portot.
A fájlfeltöltés lokálisan ment, staging-en permission denied hibát dobott – mert a mappa jogosultsága nem volt beállítva.

Mindhárom esetben: jobb staging-en derüljön ki, mint production-ban.

Feladat

Szituáció: Egy új funkciót fejlesztettél: a felhasználók PDF-et tölthetnek fel. Lokálisan tökéletesen működik – feltöltöd a fájlt, megjelenik, letölthető. Staging-re deployolva a funkció nem működik: a feltöltés látszólag lefut (nem dob hibát), de a feltöltött fájl nem jelenik meg, és letöltheti sem lehet.

Feladatod: Sorold fel legalább 5 lehetséges okot, ami miatt a staging-en nem működik a funkció, holott lokálisan igen! Minden okhoz írj egy mondatot arról is, hogyan ellenőriznéd, hogy az adott ok-e a baj.

Segítség a gondolkodáshoz:

Hol tárolja a fájlt a kód? Abszolút vagy relatív útvonalon?
Van-e írási jogosultsága az alkalmazásnak a feltöltési mappához?
Milyen URL-en érhető el a fájl? Az URL helyes a staging szerveren?
Van-e különbség a szerver konfigurációjában (fájlméret limit, feltöltési korlát)?
Van-e naplóban (logban) hibaüzenet a staging szerveren?

Tesztkérdések

1. Mi a staging környezet fő célja?

a) Hogy a fejlesztő saját gépén tesztelje a kódot
b) Hogy a valódi felhasználók elérhessék az alkalmazást
c) Hogy a production előtt, szerveren lehessen tesztelni a kódot
d) Hogy automatikusan deployoljon a production-ba

Helyes válasz: c

2. Melyik adat NEM kerülhet a verziókövető rendszerbe (.git)?

a) Az alkalmazás forráskódja
b) A .env fájl, amely adatbázis jelszót és API kulcsokat tartalmaz
c) A README.md dokumentáció
d) A tesztelési konfigurációs fájl dummy adatokkal

Helyes válasz: b

3. Párosítsd össze a szavakat!

Fogalom	Definíció
A. Local	1. Szerveren futó, de nem éles, tesztelési célú környezet
B. Staging	2. A fejlesztő saját gépén futó környezet
C. Production	3. A valódi felhasználók által használt éles környezet

Helyes párosítás: A-2, B-1, C-3

4. Melyik állítás IGAZ a logolásról?

a) Production-ban is érdemes DEBUG szintű logolást bekapcsolva hagyni, hogy könnyebb legyen a hibakeresés
b) Lokálisan nem érdemes logolni, mert csak lassítja a fejlesztést
c) Production-ban általában csak WARNING/ERROR szintű logolás javasolt, mert a DEBUG logok lassítanak és szenzitív adatot szivárogtathatnak
d) A logolási szintet a kódban kell hardcode-olni, nem konfigurációban

Helyes válasz: c

5. Lokálisan működik egy funkció, staging-en nem. Mi az első lépésed?

a) Azonnal pusholsz production-ba, hátha ott megy
b) Ellenőrzöd a staging szerver logját, hogy milyen hibát dob
c) Törlöd a staging-et és újra deployolsz
d) Feltételezed, hogy a staging-en van a hiba, és nem foglalkozol vele

Helyes válasz: b

6. Mi a különbség a „sandbox" és az „éles" API kulcs között egy fizetési rendszernél?

a) Semmi különbség, ugyanúgy működnek
b) Sandbox kulccsal valódi tranzakciókat indíthatsz, éles kulccsal nem
c) Sandbox kulccsal nem indulnak valódi tranzakciók; ez fejlesztésre és tesztelésre való
d) Az éles kulcsot lokálisan is lehet használni, a sandbox kulcsot nem

Helyes válasz: c

7. Melyik a HELYES gyakorlat a konfigurációs értékek kezelésére?

a) Az adatbázis jelszót a forráskódba írni, hogy mindenki tudja
b) Minden értéket hardcode-olni a kódba, mert így egyszerűbb
c) Környezeti változókból (DB_PASSWORD, API_KEY) olvasni a konfigurációt, és .env.example fájlt biztosítani a fejlesztőknek
d) Egyetlen konfigurációs fájlt használni minden környezethez

Helyes válasz: c

8. Melyik jelenség okozhatja, hogy egy kódfájl lokálisan betöltődik, Linux szerveren nem?

a) A Linux nem tud fájlokat olvasni
b) Linux fájlrendszeren a fájlnevek kis- és nagybetű érzékenyek; MyFile.js és myfile.js két különböző fájl
c) A szerveren nincs JavaScript értelmező
d) A fájl neve túl hosszú

Helyes válasz: b

9. Egy fejlesztő azt mondja: „Nálam működik, pusholom production-ba." Miért problémás ez a hozzáállás?

a) Nem problémás, ha a kód működik, működik
b) Mert ki kell várni a code review-t, de utána mehet production-ba
c) Mert lokális környezet és production különbözhet; staging-en való tesztelés nélkül rejtett problémák kerülhetnek élesbe
d) Mert production-ba csak a team lead pushol

Helyes válasz: c

10. Mi a deployment pipeline célja?

a) Hogy a fejlesztő manuálisan másolja a fájlokat a szerverre FTP-vel
b) Hogy automatizálja a kód staging-re és production-ra juttatásának lépéseit, beleértve a teszteket is
c) Hogy lassítsa a fejlesztési folyamatot
d) Hogy staging-et feleslegessé tegye

Helyes válasz: b