Az Software Deployment fontosságáról

Nem gondoltam volna, hogy 2013-ban még az a meglepetés ér, hogy egy projektnél nincs tisztességes software deployment. Úgy gondolom ugyanis, hogy egy magára valamit is adó projektnél nem megoldás az, hogy az előző kolléga által létrehozott file-okat úgy tudom felülírni, hogy átnevezem az azokat tartalmazó könyvtárat, vagy az adatbázis módosítást közvetlenül SQL-ben végezzük el mindennemű egységes dokumentáció nélkül. 

Képzeljük el azt a szitut, hogy a projektbe frissen került Gézácskának bele kell kontárkodnia  kódba, majd ezt el kell juttatnia az ügyfélhez. Nálunk ez úgy történik, hogy Gézácskának van saját juzere és jelszava a szerverre, amivel vagy felül tudja majd írni a kívánt fájlt, vagy nem. Ha nem, akkor vagy fel tudja hackkelni a file-okat a szerverre, vagy nem. (Esetemben fel tudtam.) Tegyük fel, hogy Gézácskának nem sok köze van a Linux jogosultságokhoz, de véletlenül kiad egy rm -rf / -t, amivel ha az OS-t nem is, de legalább a projekt file-okat (már amihez random jogosultsága van) törölni tudja. Képzeljük el ehhez még, hogy Gézácskának az adatbázisban is turkálnia kell (az élesben!), és ott kiad egy játékos drop database-t, amit amúgy azért nem fognak Gézácska nyakába varrni, mert legalább az adatbázist mindenki ugyanazzal a juzerrel kezeli.

Nyilván való (szerintem), hogy ez a rendszer az ördögtől való. Számomra normális esetben ugyanis Gézácska elkészíti a tesztkörnyezetben a file-okat, normális esetben rajta kívül teszteli valaki (de egy kis projektnél erre lehet, hogy tényleg nincs “keret”), majd elindítja a deployment procedúráját. Az én olvasatomban ez egy félautomatikus dolog, számos biztonsági mechanizmussal. Példának okáért az aktuális állapotról készül egy branch, a szerverre automatikusan kikerül a futtatható verzió, ott telepíti magát (ez akár lehet egy tarball kicsomagolása is) miután az aktuális állapotot lementette (de csak akkor települ, ha a mentés sikeres volt), majd a telepítés után automatikusan elvégzi azokat az SQL módosításokat, amikre az új verzió hibamentes futtatásához szükség van. Az egészet egy óra alatt össze lehet dobni akár bash scriptben is, de ha nagyon profik akarunk lenni, akkor ott van rá az ANT. Ráadásul olyan szinten logolom az eseményeket, ahogy nem szégyellem, és ha bárhol bármi gubanc van, akkor azonnal látszik, hogy ki mikor és hol romlott el.

Ezzel egyébként elkerülhetőek az alábbi tetszőleges események bármelyike, amik az elmúlt egy év során a projektünknél megtörténtek (és még számos más is…)

  • nincs hozzáférésem módosítani a file-okat, mert az ex-kolléga töltötte fel
  • kolléga az éles rendszeren fejleszt(!) de olyan sokági, hogy elfelejti, mit kellene “visszamásolnia”
  • hozzáférés híján nem kerülnek fel a fejlesztések a produkciós szerverre
  • “elfelejtődik” egy fejlesztés kiküldése

Mert az még egy dolog, hogy nincsenek rendes release-ek – kis projektről van szó, a nagy körforgástól magát függetlennek tartja (ámde nem az).  De az akkor sem fér a fejembe, hogy a tanult és lecserélt kollégák miért gondolták 10 éven keresztül, hogy teljesen rendjén való dolog, hogy kézzel scp-zik át a fejlesztett fájlokat a célszerverre.

Amikor 1995-ben elkezdtem az IT szektorban dolgozni, még nem tűnt ördögtől való dolognak, hogy lokálisan fejlesztünk, a verziókezelés jó esetben backup file-okkal (könyvtárakkal) történik, és a kész programot floppyn (3.5″ !) szállítjuk az ügyfélhez. Akkoriban azt se tudtam, hogy létezik CVS (amúgy volt, 1990-ben készült el az első verziója), ami már csak azért is szomorú, mert a főiskolán sem tanították.

A release-eket egyébként dátummal nevesített zip file-okban archiváltuk, még ha source kód nem is volt mindig mellette, de legalább tudtuk, hogy mi fut az ügyfélnél. (Dolgoztam olyan cégnél is, ahol a source kód és a bináris minden deploymentnél ment a backup szerverre. Ott azért jobban tudták, hogy mitől döglik a légy.)

Ez a rendszer nagyjából 2005-ig működött több KKV cégnél is, ahol szerencsém volt dolgozni, annyi különbséggel, hogy az utolsó magyar munkahelyemen korrekt távoli telepítős rendszer futott (saját fejlesztés kimondottan az adott programhoz, ami időnként még mindig inspirál).

Az ember azonban könnyen elkényelmesedik, pláne akkor, ha nagy munka árán lekódolt egy gombnyomásra működő software deployment rendszert. A “vicces” az egészben az, hogy az egészet ANT-ra írtam, ami egyrészt kvázi elavultnak tekinthető a MAVEN mellett, de akkoriban úgy döntöttünk, hogy azért ágyúval még se kell verébre lőni. Az egész XML-t viszont olyan szinten felturbóztam, hogy a compiler és build mellett a teljes (be)csomagolást, az svn branch elkészítését és a deployment előkészítését (egy svn szerverre kellett tölteni a zippelt telepítő file-okat és a hozzá tartozó SQL scripteket) is elvégezte nekem.

Amikor egy ilyen környezetből az ember bekerül egy olyan “világba” ahol az SVN sporadikusan kerül használatra és a telepítés az Oracle SQL Developer-rel valamint SSH + SCP kombinálásával kerül kivitelezésre, valamint rajtam kívül senki se garantálja, hogy minden file-t feltöltöttem a célgépre, akkor talán nem meglepő, ha egy kisebb világ dől bennem össze.

Nálad hogy kerül ki ügyfélhez a projekt?