Budapest DevOps Meetup - Deployment, build and release management

Confidential & Proprietary

Deployment, build and release management

Szabó András

2012.


Áttekintés• Deployment rendszer

– Saját igényekhez készült egyedi megoldás– Könnyen a fejlesztési folyamatokhoz

igazítható– Egyedi komponensek (pl. flash kifrissítés)– PHP

• Build folyamatok• Release management


Deployment rendszer


DEMÓ


Deployment rendszer célja

• Build folyamatok futtatása (pl. nyelvesítés, packaging)

• Forráskód eljuttatása a célszerverekre

• Rugalmas konfigurálhatóság• A szerverek változásainak gyors

követése• Monitorozás


Deployment – kézi kifrissítés


Deployment – centralizált


Deployment - SCM• SCM: Source Code Management

– Centralizált– Aszinkron műveletek: gearman jobqueue– Fájlok frissítése rsync-kel többszálon– Pre/post-commit hookok– Több verziókezelőt támogat (svn, git)– Széleskörűen konfigurálható– Monitoring– Release management


Rendszer felépítése• Központi szerver

– Repositoryk– Gearman jobqueue– Központi feldolgozók

• Kliens szerverek– Kliens feldolgozó

• Minden szervert rövid hosztneve alapján azonosítunk

• Szervereket csoportokba szervezzük


Rendszer felépítése


Központi szerver komponensei

• Verziótár hookok• Gearman jobqueue• Deployment feldolgozók (branch

típusonként egy)• Branch létrehozásra feldolgozók

(feature és release branchekre)• Válasz feldolgozó


Verziótár hookok• Pre-commit/pre-receive hook

– Autentikáció (git httpn keresztül)– Php lint– Egyéb ellenőrzések

• Post-commit/post-receive hook– Változások lekérdezése– Deploy job feladása a queueba, ha ismert és

aktív branchbe volt kommit– Deploy job már minden szükséges adatot

tartalmaz


Gearman jobqueue• Van hozzá natív PHP extension• Nincs címzés és csoportos küldés

– Egy adott névvel rendelkező job valamelyik arra a névre hallgató feldolgozóhoz kerül

• Képes a szinkron végrehajtásra, de ez nem működött megbízhatóan – amúgy is érdemesebb aszinkron folyamatkezelést megvalósítani

• Egy feladat újbóli feladásáról nekünk kell gondoskodnunk

• Perzisztens adattárolás (nem használjuk)


Gearman jobqueue• Saját PHP lib épült a gyári megoldás

fölé– Feldolgozók közös interfészt kaptak– Stabil PHP démon megvalósítás a

feldolgozókhoz– Válaszok kezelésére általános megoldás– Címzés: job nevébe került a rövid

hosztnév, pl. “Scm.Synchronize:flash56”


Gearman jobqueue• Felmerült problémák

– A feldolgozók egy idő után elárasztották a hálózatot “noop” üzenetekkel (valószínűleg bug) – rendszeres újracsatlakozás megoldotta a problémát

– Hiba esetén jobok újrafeladása: a feldolgozó réteg automatikusan kezeli


Deployment feldolgozó• Working copy létrehozása/frissítése• Szükség esetén build cleanup (ant task)• Build futtatása• Prioritás alapján szervercsoportoknak

szinkronizálási feladat• Válaszok monitorozása• Cache-ek ürítésére (pl. APC flush) jobok

feladása


Egyéb feldolgozók• Feature/release branch létrehozására

1-1 feldolgozó– Branch létrehozása a repositoryban– Igény szerint working copy létrehozása

(git esetében)

• Válaszok feldolgozása– Külön démon végzi, különböző

válaszjobokra van feliratkozva


Kliens oldali kifrissítés• Egy feldolgozó (gyakran szűk

keresztmetszet)• Szinkronizálás job:

– Rsyncet futtat (nagyobb io/hálózati terhelés esesén lassú)

– Branch törlés/létrehozás– Fájljogosultságok (chown)– Éles release branch kiválasztása (symlink

váltás)• APC flush job (lokális url meghívása)


Szerverek teljes kifrissítése

• Külön job• Hasznos új szerver üzembehelyezése

után vagy sokáig kiesett szerver frissítéséhez

• Szerverek kifrissítési állapotának ellenőrzése– Minden repository/branchhez

verzióellenőrzés


Rendszer karbantartása• Update system script

– Kliensek ellenőrzése (státusz, verzió)– Kliensek frissítése (giten keresztül)– Kliensek leállítása– Kliensek státusza felületen

nyomonkövethető

• Feldolgozó démonok aktív figyelése– monit


SCM monitor


Konfiguráció• Fő egység a projekt

– Build konfiguráció, APC beállítások• Projekten belül több repository• Repositoryn belül branchek

– Minden branchnek egyedi kifrissítési konfiguráció (milyen szervercsoportok mely szervereire menjen a kifrissítés)

• Egy projekten belül több kifrissítési konfiguráció (pl. feature/release branchekre külön)


Egyedi modulok• Flash alkalmazások kezelése

– Egyedi verziókezelés és deployment– Munka branchek, trunk/prelive/live

kontextek kezelése– Minden branchhez egyedi

verziókonfigurácók adhatóak meg– Könnyű visszaállási lehetőség


Egyéb szolgáltatások• Virtuális branchek kezelése (symlinkelt

könyvtárak, pl. csapat release branch)• Deployment parancsok commit

messageből– APC flush vezérlése (pl. nagy terheléscsúcs)– Build előtt cleanup

• Live release rss feed• Lehet kommitokat lájkolni


BUILD folyamatok


Build folyamat célja• A rendszer gyorsítása előfeldolgozással• Feladatai:

– Js/css fájlok tömörítése, csomagolása– Dinamikus fordításhoz nyelvesítési adatok

kigyűjtése– Template-ek nyelvesítése– Statikus tartalmak verziózása– PHP osztályok összecsomagolása

• 10 nyelv mellett 30-60 sec között fut


Nyelvesítés• Saját nyelvesítési rendszer• A build folyamat automatikusan

feltérképezi, milyen template milyen nyelvi elemeket használ

• Újrabuildelés csak a változott fájlok/változott nyelvi elemek alapján

• Dinamikus fordítások feldarabolása (nyelvenként ~160 kicsi adatfájl)


js/css csomagolás, verziózás

• YUI Compressor js és css fájlokra• Oldaltípusonként külön js és css

csoportokat csomagolunk össze (pl. channel/dashboard)

• Minden statikus tartalom utolsó fájlmódosítási dátum alapján kap verziót

• Css fájlokba injektáljuk a verziókat• Statikus tartalmat nagyrészét nginx/cdn

szolgálja ki


PHP osztályok csomagolása

• Saját framework osztályok• Leggyakrabban használt üzleti

logikát megvalósító osztályok• Összeállítása kézzel történik

(érdemes lenne rendszeresen monitorozni a hatékonyságot)

• Mérete: ~1Mb jelenleg


Release management


Release management• A jó folyamat kiválasztása erősen

termék és cégfüggő• Igazodnia kell a megrendelők

(termékmenedzserek) igényeihez• Ustream: számos azonnali módosítás

és gyorsjavítás – be kell tudni illeszteni a napi folyamatokba


Régi út• Minden fejlesztés és tesztelés a

trunkban• Élesítés közvetlenül a stagebe

– Lassú élesítés– Nehézkes a visszahúzás– Trunk/stage környezet eltérése miatt

gyakori hibák

• Trunkban rengeteg halott kód gyűlt fel, egyre nehezebb a karbantartás


Brancheljünk?• Fő ág a stage/master branch• Minden branch a fő ágból ágazik el• Feature branchek a fejlesztéshez,

elsőkörös QA-hoz• Release branchek az élesítés

előkészítéséhez, végleges QA-hoz• Élesítés csak a release branch

váltását jelenti, könnyű visszavonás


Feature branchek• Minden fejlesztés kisebb-nagyobb

feature és csapat branchekben folyik• Csapat branchek főleg demózáshoz,

komponensek összeillesztéséhez, de rövid időn belül halott kódot tartalmazhatnak

• A termékmenedzserek felől érkező állandóan változó igények miatt nehéz a brancheket karbantartani


Fokozatos refactoring• Branchelés helyett refaktorizálás a fő

ágban közvetlenül– Adott komponensben új absztrakciós

réteg bevezetése– Új üzleti logika megvalósítása– Fokozatos átállás az új megvalósításra– Ha a régi kódokat már semmi nem

használja, az absztrakciós réteg megszüntethető


Élesítés folyamata• Release branch létrehozása (nem tag!)

– Tesztelés minél közelebb az éles rendszerhez

• Éles release branch váltás:– Nincs kiemelt esemény abban az időszakban

(pl. sokezer dolláros ppv adás)– CI buildek hiba nélkül futnak– QA-n átment– Szükség esetén sysop/backend csapat review

• Live váltás/rollback egy kattintás


Élesítések ütemezése• SCM felületen a csapatok előre

felviszik az élesítési időpontokat• Scrum szerint dolgozó csapatok a

sprintek szerint release-elnek• Pl. backend csapat fix heti release-

eket csinál• Fontos módosítás esetén quickfix

release/élesbe kommitolás engedélyezett


Élesítés naptár


Continuous integration• Különálló Jenkins szerver

– Repository mirrorból dolgozik (gyors)– Branchenként külön jobok– Unit/db/integrációs/end-to-end tesztek

futtatása minden kommit után (gyors)– Nightly build: code coverage, statikus

analízis futtatás (lassú)– Párhuzamos buildek futattása izoláltan

(saját db, memcache pooling)


Továbbfejlesztési irányok• Jelenleg sok adminisztrációs munka

– Release log karbantartása (JIRA ticketek alapján kigyűjthető)

• Pre-commit/release hook– JIRA ticketek ellenőrzése– Phpcs futtatás változott fájlokra

• Release folyamat jobbá tétele, folyamatos kód integráció


KÖSZÖNÖM A FIGYELMET!Jöhetnek a kérdések.

Technology

Budapest DevOps Meetup - Deployment, build and release management