Több interjút is készítettünk mostanában azzal kapcsolatban, milyen módszertanok és értékek mentén működünk együtt. Ezúttal Gáborral (Technical Lead) és Szilveszterrel (Dev Lead) beszélgettünk arról, ők hogyan igyekeznek még hatékonyabbá tenni a közös munkát, illetve támogatni a projekteket mind fejlesztési, mind DevOps oldalról. 

Úgy tudom, viszonylag újdonságnak számít nálunk a Docker Swarm. Tudnátok erről az eszközről mesélni?

Szilveszter: Igyekeztünk a fejlesztők számára megkönnyíteni a deployment folyamatot többféle szempontból, azzal a céllal, hogy minél kevesebb manualitás legyen benne; illetve szerettük volna a szervereink terhelését is elosztani – részben ezért vezettük be a Docker Swarmot. 

Gábor: A Docker Swarm egy clusterezési és ütemező eszköz, amely a projektek futtatási módszerének egy szofisztikáltabb módját teszi lehetővé. Segítségével a fejlesztők számára egyszerűbbé vált a deployment, és a domain választás is automatizált lett bizonyos keretek között. A stabilitás a kulcsszó: ez a projekteknek egy olyan development környezete, amely a házon belüli szerveren fut, ezáltal stabilabb. Folyamatában vezettük be, december-január óta már az összes projektnél sikerült ezt meglépni.

Mi volt a célja a Projekt sablon létrehozásának?

Szilveszter: Készítettünk egy olyan példakódokat tartalmazó projektindító sablont, amely a fejlesztők segítségére lehet abban, hogyan kell inicializálni egy projektet, illetve hogyan konfigurálják fel a pipeline-t, tehát CI/CD folyamatot. Nem implementációról van szó, a létrehozásával az volt a célunk, hogy legyen miből kiindulniuk. 

Gábor: Iránymutató sablonnak nevezném,  bevezetése pedig a céges célokat is támogatja. A mi indíttatásunk leginkább onnan jött, hogy szerettünk volna olyan megoldásokat beépíteni, amelyek a vezetőség által kitűzött célokat IT oldalról támogatni tudják. A dokumentációja pedig elérhető a 2019-ben létrehozott belső Wiki felületünkön, amelyen többek között a mindenki számára hasznos általános technikai információkat és beállításokat gyűjtjük össze. 

Mit érdemes tudni a Development policyról?

Szilveszter: Ez szorosan kapcsolódik az előbb említett projektindító sablonhoz. A Development policy olyan alapvető dolgokban nyújt iránymutatást, mint a projekt konfigurálása vagy akár a kódolás. Megpróbáltunk egy szabványt keresni, de ettől függetlenül mindenkinek van és lehet beleszólása a policyba, a cél az, hogy közösen alakítsuk ki. Ezek megvitatására dedikált fórum a DevMeeting, ahol adott a lehetőség az ezekről való beszélgetésre. 

Esetleg kiemelnétek még valamit? A jelszókezelő bevezetése jutott eszembe. 

Gábor: A BitWarden jelszókezelő szoftverünk azt a célt szolgálja, hogy biztonságos és egységes módon tároljuk a jelszavainkat. Ennek köszönhetően mindenkinek megvan a lehetősége arra, hogy saját jelszavakat tároljon, de ezeket meg is lehet egymással osztani, és lehetőség van arra is, hogy csak a csapattagok férjenek hozzá az ügyfelek jelszavaihoz, stb. Korábban is használtunk jelszókezelőt, a Passpack-et, viszont az nem volt ennyire részletesen kidolgozva – a jelenlegi szoftvert az adott lehetőségekhez mérten magunkra, a saját működésünkre szabtuk. 

Milyen újítások vannak jelenleg folyamatban vagy tervben?

Gábor: Általánosságban elkezdtünk foglalkozni a kódújrahasznosítás témakörével, bevezetésével, többféle aspektusból megvizsgálva a kérdést. Szilveszter Dev Lead szerepköre pont erről szól, hogy olyan fejlesztési módszereket terjesszen a csapatokon belül, amelyek ezt a kódújrahasznosítást szolgálják. Több ember bevonásával elkezdtünk arról gondolkodni, hogy ez hogyan érinti a PM munkát, a projektbecsléseket, fogja-e, és ha igen, milyen irányba és mikor változtatni a büdzséket, tudunk-e majd olcsóbban összerakni projektet, illetve hogy mindez mikor fogja ez érinteni a sales tevékenységét is.  

Illetve hamarosan érkezik az irodába egy új szerver is, amellyel nem a helyettesítés, hanem a kiegészítés lesz a cél. Orvosolni akarjuk vele azt, hogy a régi szerver lassúnak bizonyult az automatizált folyamatok közben. Egyéb házon belüli szolgáltatásokat is szeretnénk átszervezni, ezek nem a gyorsaságot, hanem a stabilitást fogják garantálni, pl. a Mattermostnál, a belső céges kommunikációs eszközünknél. 

Vannak nagyra törő terveink is, például a Kubernetest szeretnénk megtanulni és bevezetni, mert ez az új szerver már alkalmas lesz erre is. Ez főleg nagy és komplex projektek esetén lenne hasznos számunkra, és mivel ilyenek vannak tervben, úgy gondoljuk, hogy 1-3 éves távlatban elengedhetetlen, hogy a Kubernetest is elsajátítsuk.