Az én gépemen működik: mi ez, miért történik és hogyan előzzük meg

Mit jelent „Az én gépemen működik”

„Az én gépemen működik” — a mondat, amit a fejlesztő akkor mond, amikor egy kolléga vagy tesztelő hibát jelent, de a fejlesztő gépén ez a hiba nem reprodukálható. Külsőre ez a probléma tagadásának tűnik, de technikailag a helyzet valós: a kód tényleg működhet az egyik környezetben és összeomolhat a másikban. Egyetlen bitnyi konfigurációs különbség — és az alkalmazás viselkedése gyökeresen megváltozik.

A mondás mém lett az IT-közösségben, mert egyszerre igaz és haszontalan. A fejlesztő szemszögéből — a kód tényleg működik az ő gépén. A csapat szemszögéből — a probléma létezik és meg kell oldani, nem pedig igazolni. A helyzet humora abban rejlik, hogy a fejlesztő igazat mond, de ez az igazság nem segít kijavítani a hibát. A mém annyira népszerű, hogy ezer meg ezer posztot szenteltek neki a Redditen, az XKCD-n és a DevOps konferenciákon.

A folyamatok szemszögéből az „az én gépemen működik” mondat a környezet reprodukálhatóságával kapcsolatos problémák jelzője. Ha két fejlesztő nem tud ugyanarra a kódra ugyanazt az eredményt kapni — akkor a környezet beállításának folyamata nem szabványosított. A DevOps gyakorlat szerint: a környezetnek egyetlen parancs segítségével reprodukálhatónak kell lennie a repóból, kézi műveletek nélkül.

Miért tér el a lokális környezet az éles környezettől

A fejlesztő lokális környezete szinte mindig eltér az éles környezettől. A fejlesztő macOS-t vagy Windows-t használ, míg a szerver Linuxon fut. A különböző operációs rendszerek eltérő fájlrendszerekkel, kódolásokkal, szálak időzítésével és rendszerhívásokkal rendelkeznek. Még ha mindkét környezet Linux is — a kernelverzió, a glibc, az OpenSSL eltérhet.

A második ok — a telepített szoftverek készlete. A fejlesztő gépén lehet, hogy a Node.js 20 globális verziója van telepítve, míg a CI/CD konfigurációban a 18-as verzió van megadva. Vagy a fejlesztő lokálisan PostgreSQL 16-ot használ, élesben pedig PostgreSQL 14-et. A kisebb verziók közötti különbségek gyakran nem észrevehetők, de a nagyobb frissítések megváltoztathatják az SQL-lekérdezések viselkedését. Az npm Inc. szerint a függőségekkel kapcsolatos hibák 67%-át a patch-verziók közötti különbség okozza.

A harmadik ok — hálózati körülmények. A lokális gépen nincsenek késleltetések, sávszélesség-korlátozások és DNS-problémák. Élesben bármely külső API-nak küldött kérés 500 ms-ig is tarthat 5 ms helyett. Időtúllépések, újrapróbálkozási logika, versenyhelyzetek — ezek a problémák csak valós terhelés alatt és valós hálózati körülmények között jelentkeznek. A hálózat emulálása olyan eszközökkel, mint a Toxiproxy, segít ezeket a problémákat a telepítés előtt azonosítani.

A hiba lokális reprodukálhatatlanságának tipikus okai

Az első ok — az adatok hiánya. A fejlesztő tesztadatokkal dolgozik, míg élesben millió olyan rekord van, amelyek váratlan értékeket tartalmazhatnak. NULL egy olyan mezőben, amelyet a fejlesztő kötelezőnek vélt, Unicode-karakter egy névben, túl hosszú sztring — mindezek olyan hibákat okozhatnak, amelyek nem reprodukálhatók a szintetikus adatokkal rendelkező lokális adatbázison.

A második ok — különböző fordítási és build kapcsolók. A kiadási build (Release/Distribution) eltérhet a hibakeresési buildtől (Debug). A fordítóoptimalizálások, a debug naplók eltávolítása, a függvények beillesztése — ezek mind elrejthetik vagy éppen ellenkezőleg, megjeleníthetik a hibákat. Tipikus példa: a debug buildben működik egy assert, amely a release buildben a változók eltérő inicializálási sorrendje miatt összeomlik.

A harmadik ok — lokális gyorsítótár és ideiglenes fájlok. A fejlesztő esetleg nem veszi észre a hibát, mert a böngészőben régi szkriptek vannak gyorsítótárazva, a Redisben elavult adatok vannak mentve, a fájlrendszerben pedig korábbi futtatásokból származó ideiglenes fájlok lógnak. Egy tiszta indítás (inkognitómód, gyorsítótár törlése, friss telepítés) gyakran reprodukálja a hibát, amely „magától” nem jelentkezett.

A negyedik ok — a globális és lokális függőségek közötti konfliktusok. Az olyan eszközök, mint a Ruby gems, a Python pip, a Node.js npm rendelkezhetnek globálisan telepített csomagokkal, amelyek „segítenek” a kódnak lokálisan működni, de hiányoznak élesben. A virtuális környezetek (virtualenv, venv, nvm) használata elkülöníti a projektet a globális telepítésektől, és reprodukálhatóvá teszi a környezetet.

Hatás a csapatmunkára és a bizalomra

Az „az én gépemen működik” mondat lerombolja a bizalmat a csapatban. Ha egy fejlesztő rendszeresen nem tudja reprodukálni a hibákat, a kollégák elkezdenek kételkedni a kompetenciájában vagy a tesztelés alaposságában. Idővel ez mikromenedzsmenthez vezet: minden változtatást egy második fejlesztőnek kell ellenőriznie, ami lassítja a fejlesztést. A Google Project Aristotle szerint a pszichológiai biztonság a csapatban közvetlenül befolyásolja a termelékenységet, és a környezetről szóló állandó viták az egyik tényezője annak csökkenésének.

A második probléma — a code review lelassulása. Ha egy fejlesztő nem tudja lokálisan reprodukálni a hibát, elutasíthatja a kolléga pull requestjét azzal, hogy „nálam működik — szóval nálad a probléma”. Ez konfliktusokat vált ki és késlelteti a funkciók szállítását. A környezet szabványosítása megszünteti ezt a konfliktust: ha mindkét fejlesztő ugyanabban a Docker-tárolóban dolgozik, a „kinél működik” kérdés értelmét veszti.

A harmadik probléma — a hibák elvesztése a nyomkövetőben. A „a fejlesztőnél nem reprodukálható” hibákat gyakran a „nem reprodukálható” (Cannot Reproduce) megjegyzéssel zárják le. Egy hónap múlva a hiba előbukkan élesben, és a javítása 10-szer többe kerül. A szabály: ha a hiba legalább egy embernél reprodukálható — létezik, függetlenül attól, hogy a fejlesztőnél működik-e vagy sem.

Hogyan szabványosítsuk a fejlesztői környezetet

Az első és leghatékonyabb módszer — Docker. Az egész projektnek el kell indulnia a docker-compose up paranccsal további műveletek nélkül. Az adatbázis, a gyorsítótár, az üzenetsor, a webkiszolgáló — minden konténerekben indul el. A fejlesztő csak a Dockert és a Gitet telepíti. A többi — a konténereken belül. Ez garantálja, hogy a csapat minden tagja ugyanazzal a környezettel rendelkezik, függetlenül az operációs rendszertől.

A második módszer — verziókezelők. Ha a Docker nem lehetséges (licenckorlátozások, örökölt infrastruktúra), használja az nvm (Node.js), rbenv (Ruby), pyenv (Python), sdkman (Java) eszközöket. A verziókezelők lehetővé teszik a nyelvek és eszközök verzióinak váltását a projekten belül. A .nvmrc, .ruby-version, .python-version fájloknak a repóban kell lenniük, és a CI/CD-nek ellenőriznie kell azokat.

A harmadik módszer — Vagrant virtuális gépekhez. A Vagrant egy megadott operációs rendszerrel és konfigurációval rendelkező virtuális gépet indít a VirtualBox vagy VMware tetején. A virtuális gépen belül az összes függőség kiépítő szkriptek (shell, Ansible, Puppet) segítségével települ. A Vagrant nehezebb, mint a Docker, de teljes elkülönítést biztosít az operációs rendszer szintjén — hasznos olyan projektekhez, amelyek a Linux kernel egy adott verziójától függenek.

A negyedik — makefile és bootstrap szkriptek. Még egy egyszerű Makefile az install, test, build, clean célokkal is szabványosíthatja a rutinműveleteket. A make install parancsnak telepítenie kell az összes függőséget, konfigurálnia kell az adatbázist, és létre kell hoznia a tesztadatokat. Egységes belépési pont az összes fejlesztő számára kizárja a kézi hibákat a környezet beállításakor.

Eszközök a környezeti eltérések megelőzésére

A fő eszköz — a függőségek lock-fájljai. A package-lock.json (npm), yarn.lock (Yarn), Podfile.lock (CocoaPods), pubspec.lock (Flutter) rögzítik az egyes csomagok pontos verzióját. Lock-fájl nélkül két, különböző időpontban telepítő fejlesztő eltérő kisebb verziókat kaphat. A lock-fájlnak a repóban kell lennie, és nem szabad kézzel szerkeszteni.

A második eszköz — .env.example a repóban. A környezeti változók sablonfájlja megjegyzésekkel. A fejlesztő bemásolja .env-be, és kitölti a saját értékeit. A CI/CD pipeline ellenőrzi, hogy az összes kötelező változó be van-e állítva. A GitLab 2023 szerint a .env.example-t használó csapatok 40%-kal csökkentik a környezeti változókkal kapcsolatos incidensek számát.

A harmadik eszköz — pre-commit hookok. Automatikus ellenőrzés, amely minden commit előtt lefut: linter, formázó, típusellenőrzés, tesztek. Ha a hookok minden fejlesztőnél azonos módon vannak beállítva, akkor a „lokális gépen átment” formázási vagy típushibák nem jutnak el élesbe. A Husky JavaScripthez és a pre-commit Pythonhoz népszerű megoldások.

A negyedik — CI/CD pipeline, amely tiszta környezetben futtatja a teszteket. Ha a tesztek átmennek CI-ben, de lokálisan nem — a probléma a lokális környezet beállításában van. Ha a tesztek nem mennek át CI-ben — a pull request nem kerül beolvasztásra. Ez a szigorú szabály kizárja a „lokálisan működő” hibák bekerülését a fő ágba.