Deployment, build and release management Szabó András 2012.
Áttekintés <ul><li>Deployment rendszer </li></ul><ul><ul><li>Saját igényekhez készült egyedi megoldás </li></ul></ul><ul><...
Deployment rendszer
DEMÓ
Deployment rendszer célja <ul><li>Build folyamatok futtatása (pl. nyelvesítés, packaging) </li></ul><ul><li>Forráskód elju...
Deployment – kézi kifrissítés
Deployment – centralizált
Deployment - SCM <ul><li>SCM: Source Code Management </li></ul><ul><ul><li>Centralizált </li></ul></ul><ul><ul><li>Aszinkr...
Rendszer felépítése <ul><li>Központi szerver </li></ul><ul><ul><li>Repositoryk </li></ul></ul><ul><ul><li>Gearman jobqueue...
Rendszer felépítése
Központi szerver komponensei <ul><li>Verziótár hookok </li></ul><ul><li>Gearman jobqueue </li></ul><ul><li>Deployment feld...
Verziótár hookok <ul><li>Pre-commit/pre-receive hook </li></ul><ul><ul><li>Autentikáció (git httpn keresztül) </li></ul></...
Gearman jobqueue <ul><li>Van hozzá natív PHP extension </li></ul><ul><li>Nincs címzés és csoportos küldés </li></ul><ul><u...
Gearman jobqueue <ul><li>Saját PHP lib épült a gyári megoldás fölé </li></ul><ul><ul><li>Feldolgozók közös interfészt kapt...
Gearman jobqueue <ul><li>Felmerült problémák </li></ul><ul><ul><li>A feldolgozók egy idő után elárasztották a hálózatot “n...
Deployment feldolgozó <ul><li>Working copy létrehozása/frissítése </li></ul><ul><li>Szükség esetén build cleanup (ant task...
Egyéb feldolgozók <ul><li>Feature/release branch létrehozására 1-1 feldolgozó </li></ul><ul><ul><li>Branch létrehozása a r...
Kliens oldali kifrissítés <ul><li>Egy feldolgozó (gyakran szűk keresztmetszet) </li></ul><ul><li>Szinkronizálás job: </li>...
Szerverek teljes kifrissítése <ul><li>Külön job </li></ul><ul><li>Hasznos új szerver üzembehelyezése után vagy sokáig kies...
Rendszer karbantartása <ul><li>Update system script </li></ul><ul><ul><li>Kliensek ellenőrzése (státusz, verzió) </li></ul...
SCM monitor
Konfiguráció <ul><li>Fő egység a projekt </li></ul><ul><ul><li>Build konfiguráció, APC beállítások </li></ul></ul><ul><li>...
Egyedi modulok <ul><li>Flash alkalmazások kezelése </li></ul><ul><ul><li>Egyedi verziókezelés és deployment </li></ul></ul...
Egyéb szolgáltatások <ul><li>Virtuális branchek kezelése (symlinkelt könyvtárak, pl. csapat release branch) </li></ul><ul>...
BUILD folyamatok
Build folyamat célja <ul><li>A rendszer gyorsítása előfeldolgozással </li></ul><ul><li>Feladatai: </li></ul><ul><ul><li>Js...
Nyelvesítés <ul><li>Saját nyelvesítési rendszer </li></ul><ul><li>A build folyamat automatikusan feltérképezi, milyen temp...
js/css csomagolás, verziózás <ul><li>YUI Compressor js és css fájlokra </li></ul><ul><li>Oldaltípusonként külön js és css ...
PHP osztályok csomagolása <ul><li>Saját framework osztályok </li></ul><ul><li>Leggyakrabban használt üzleti logikát megval...
Release management
Release management <ul><li>A jó folyamat kiválasztása erősen termék és cégfüggő </li></ul><ul><li>Igazodnia kell a megrend...
Régi út <ul><li>Minden fejlesztés és tesztelés a trunkban </li></ul><ul><li>Élesítés közvetlenül a stagebe </li></ul><ul><...
Brancheljünk? <ul><li>Fő ág a stage/master branch </li></ul><ul><li>Minden branch a fő ágból ágazik el </li></ul><ul><li>F...
Feature branchek <ul><li>Minden fejlesztés kisebb-nagyobb feature és csapat branchekben folyik </li></ul><ul><li>Csapat br...
Fokozatos refactoring <ul><li>Branchelés helyett refaktorizálás a fő ágban közvetlenül </li></ul><ul><ul><li>Adott kompone...
Élesítés folyamata <ul><li>Release branch létrehozása (nem tag!) </li></ul><ul><ul><li>Tesztelés minél közelebb az éles re...
Élesítések ütemezése <ul><li>SCM felületen a csapatok előre felviszik az élesítési időpontokat </li></ul><ul><li>Scrum sze...
Élesítés naptár
Continuous integration <ul><li>Különálló Jenkins szerver </li></ul><ul><ul><li>Repository mirrorból dolgozik (gyors) </li>...
Továbbfejlesztési irányok <ul><li>Jelenleg sok adminisztrációs munka </li></ul><ul><ul><li>Release log karbantartása (JIRA...
KÖSZÖNÖM A FIGYELMET! <ul><li>Jöhetnek a kérdések. </li></ul>
Upcoming SlideShare
Loading in …5
×

Budapest DevOps Meetup - Deployment, build and release management

1,213 views

Published on

http://www.meetup.com/devopsbp/events/50529942/

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,213
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
12
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide
  • A fejlesztők kommitolnak a központi repositoryba, majd kézzel frissítik a szervereken a forráskódot. Ez 1-2 szerver esetén működhet is, de még akkor is nagyon kényelmetlen.
  • Ustream korábbi kifrissítő rendszere. Mindössze néhány PHP fájlból állt. Hook indukálta a build + kifrissítést, ami lineárisan futtatott rsyncelésből állt. Egyszerű monitoring felület, BLINK tag!  Konfiguráció PHP fájlban.
  • Szervereken szintén job processor
  • Ha felülírunk egy statikus fájlt (pl. képet), akkor az új módosítási dátum miatt új verziót kap, ezzel a felhasználók garantáltan a friss verziót kapják.
  • Budapest DevOps Meetup - Deployment, build and release management

    1. 1. Deployment, build and release management Szabó András 2012.
    2. 2. Áttekintés <ul><li>Deployment rendszer </li></ul><ul><ul><li>Saját igényekhez készült egyedi megoldás </li></ul></ul><ul><ul><li>Könnyen a fejlesztési folyamatokhoz igazítható </li></ul></ul><ul><ul><li>Egyedi komponensek (pl. flash kifrissítés) </li></ul></ul><ul><ul><li>PHP </li></ul></ul><ul><li>Build folyamatok </li></ul><ul><li>Release management </li></ul>
    3. 3. Deployment rendszer
    4. 4. DEMÓ
    5. 5. Deployment rendszer célja <ul><li>Build folyamatok futtatása (pl. nyelvesítés, packaging) </li></ul><ul><li>Forráskód eljuttatása a célszerverekre </li></ul><ul><li>Rugalmas konfigurálhatóság </li></ul><ul><li>A szerverek változásainak gyors követése </li></ul><ul><li>Monitorozás </li></ul>
    6. 6. Deployment – kézi kifrissítés
    7. 7. Deployment – centralizált
    8. 8. Deployment - SCM <ul><li>SCM: Source Code Management </li></ul><ul><ul><li>Centralizált </li></ul></ul><ul><ul><li>Aszinkron műveletek: gearman jobqueue </li></ul></ul><ul><ul><li>Fájlok frissítése rsync-kel többszálon </li></ul></ul><ul><ul><li>Pre/post-commit hookok </li></ul></ul><ul><ul><li>Több verziókezelőt támogat (svn, git) </li></ul></ul><ul><ul><li>Széleskörűen konfigurálható </li></ul></ul><ul><ul><li>Monitoring </li></ul></ul><ul><ul><li>Release management </li></ul></ul>
    9. 9. Rendszer felépítése <ul><li>Központi szerver </li></ul><ul><ul><li>Repositoryk </li></ul></ul><ul><ul><li>Gearman jobqueue </li></ul></ul><ul><ul><li>Központi feldolgozók </li></ul></ul><ul><li>Kliens szerverek </li></ul><ul><ul><li>Kliens feldolgozó </li></ul></ul><ul><li>Minden szervert rövid hosztneve alapján azonosítunk </li></ul><ul><li>Szervereket csoportokba szervezzük </li></ul>
    10. 10. Rendszer felépítése
    11. 11. Központi szerver komponensei <ul><li>Verziótár hookok </li></ul><ul><li>Gearman jobqueue </li></ul><ul><li>Deployment feldolgozók (branch típusonként egy) </li></ul><ul><li>Branch létrehozásra feldolgozók (feature és release branchekre) </li></ul><ul><li>Válasz feldolgozó </li></ul>
    12. 12. Verziótár hookok <ul><li>Pre-commit/pre-receive hook </li></ul><ul><ul><li>Autentikáció (git httpn keresztül) </li></ul></ul><ul><ul><li>Php lint </li></ul></ul><ul><ul><li>Egyéb ellenőrzések </li></ul></ul><ul><li>Post-commit/post-receive hook </li></ul><ul><ul><li>Változások lekérdezése </li></ul></ul><ul><ul><li>Deploy job feladása a queueba, ha ismert és aktív branchbe volt kommit </li></ul></ul><ul><ul><li>Deploy job már minden szükséges adatot tartalmaz </li></ul></ul>
    13. 13. Gearman jobqueue <ul><li>Van hozzá natív PHP extension </li></ul><ul><li>Nincs címzés és csoportos küldés </li></ul><ul><ul><li>Egy adott névvel rendelkező job valamelyik arra a névre hallgató feldolgozóhoz kerül </li></ul></ul><ul><li>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 </li></ul><ul><li>Egy feladat újbóli feladásáról nekünk kell gondoskodnunk </li></ul><ul><li>Perzisztens adattárolás (nem használjuk) </li></ul>
    14. 14. Gearman jobqueue <ul><li>Saját PHP lib épült a gyári megoldás fölé </li></ul><ul><ul><li>Feldolgozók közös interfészt kaptak </li></ul></ul><ul><ul><li>Stabil PHP démon megvalósítás a feldolgozókhoz </li></ul></ul><ul><ul><li>Válaszok kezelésére általános megoldás </li></ul></ul><ul><ul><li>Címzés: job nevébe került a rövid hosztnév, pl. “Scm.Synchronize:flash56” </li></ul></ul>
    15. 15. Gearman jobqueue <ul><li>Felmerült problémák </li></ul><ul><ul><li>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 </li></ul></ul><ul><ul><li>Hiba esetén jobok újrafeladása: a feldolgozó réteg automatikusan kezeli </li></ul></ul>
    16. 16. Deployment feldolgozó <ul><li>Working copy létrehozása/frissítése </li></ul><ul><li>Szükség esetén build cleanup (ant task) </li></ul><ul><li>Build futtatása </li></ul><ul><li>Prioritás alapján szervercsoportoknak szinkronizálási feladat </li></ul><ul><li>Válaszok monitorozása </li></ul><ul><li>Cache-ek ürítésére (pl. APC flush) jobok feladása </li></ul>
    17. 17. Egyéb feldolgozók <ul><li>Feature/release branch létrehozására 1-1 feldolgozó </li></ul><ul><ul><li>Branch létrehozása a repositoryban </li></ul></ul><ul><ul><li>Igény szerint working copy létrehozása (git esetében) </li></ul></ul><ul><li>Válaszok feldolgozása </li></ul><ul><ul><li>Külön démon végzi, különböző válaszjobokra van feliratkozva </li></ul></ul>
    18. 18. Kliens oldali kifrissítés <ul><li>Egy feldolgozó (gyakran szűk keresztmetszet) </li></ul><ul><li>Szinkronizálás job: </li></ul><ul><ul><li>Rsyncet futtat (nagyobb io/hálózati terhelés esesén lassú) </li></ul></ul><ul><ul><li>Branch törlés/létrehozás </li></ul></ul><ul><ul><li>Fájljogosultságok (chown) </li></ul></ul><ul><ul><li>Éles release branch kiválasztása (symlink váltás) </li></ul></ul><ul><li>APC flush job (lokális url meghívása) </li></ul>
    19. 19. Szerverek teljes kifrissítése <ul><li>Külön job </li></ul><ul><li>Hasznos új szerver üzembehelyezése után vagy sokáig kiesett szerver frissítéséhez </li></ul><ul><li>Szerverek kifrissítési állapotának ellenőrzése </li></ul><ul><ul><li>Minden repository/branchhez verzióellenőrzés </li></ul></ul>
    20. 20. Rendszer karbantartása <ul><li>Update system script </li></ul><ul><ul><li>Kliensek ellenőrzése (státusz, verzió) </li></ul></ul><ul><ul><li>Kliensek frissítése (giten keresztül) </li></ul></ul><ul><ul><li>Kliensek leállítása </li></ul></ul><ul><ul><li>Kliensek státusza felületen nyomonkövethető </li></ul></ul><ul><li>Feldolgozó démonok aktív figyelése </li></ul><ul><ul><li>monit </li></ul></ul>
    21. 21. SCM monitor
    22. 22. Konfiguráció <ul><li>Fő egység a projekt </li></ul><ul><ul><li>Build konfiguráció, APC beállítások </li></ul></ul><ul><li>Projekten belül több repository </li></ul><ul><li>Repositoryn belül branchek </li></ul><ul><ul><li>Minden branchnek egyedi kifrissítési konfiguráció (milyen szervercsoportok mely szervereire menjen a kifrissítés) </li></ul></ul><ul><li>Egy projekten belül több kifrissítési konfiguráció (pl. feature/release branchekre külön) </li></ul>
    23. 23. Egyedi modulok <ul><li>Flash alkalmazások kezelése </li></ul><ul><ul><li>Egyedi verziókezelés és deployment </li></ul></ul><ul><ul><li>Munka branchek, trunk/prelive/live kontextek kezelése </li></ul></ul><ul><ul><li>Minden branchhez egyedi verziókonfigurácók adhatóak meg </li></ul></ul><ul><ul><li>Könnyű visszaállási lehetőség </li></ul></ul>
    24. 24. Egyéb szolgáltatások <ul><li>Virtuális branchek kezelése (symlinkelt könyvtárak, pl. csapat release branch) </li></ul><ul><li>Deployment parancsok commit messageből </li></ul><ul><ul><li>APC flush vezérlése (pl. nagy terheléscsúcs) </li></ul></ul><ul><ul><li>Build előtt cleanup </li></ul></ul><ul><li>Live release rss feed </li></ul><ul><li>Lehet kommitokat lájkolni  </li></ul>
    25. 25. BUILD folyamatok
    26. 26. Build folyamat célja <ul><li>A rendszer gyorsítása előfeldolgozással </li></ul><ul><li>Feladatai: </li></ul><ul><ul><li>Js/css fájlok tömörítése, csomagolása </li></ul></ul><ul><ul><li>Dinamikus fordításhoz nyelvesítési adatok kigyűjtése </li></ul></ul><ul><ul><li>Template-ek nyelvesítése </li></ul></ul><ul><ul><li>Statikus tartalmak verziózása </li></ul></ul><ul><ul><li>PHP osztályok összecsomagolása </li></ul></ul><ul><li>10 nyelv mellett 30-60 sec között fut </li></ul>
    27. 27. Nyelvesítés <ul><li>Saját nyelvesítési rendszer </li></ul><ul><li>A build folyamat automatikusan feltérképezi, milyen template milyen nyelvi elemeket használ </li></ul><ul><li>Újrabuildelés csak a változott fájlok/változott nyelvi elemek alapján </li></ul><ul><li>Dinamikus fordítások feldarabolása (nyelvenként ~160 kicsi adatfájl) </li></ul>
    28. 28. js/css csomagolás, verziózás <ul><li>YUI Compressor js és css fájlokra </li></ul><ul><li>Oldaltípusonként külön js és css csoportokat csomagolunk össze (pl. channel/dashboard) </li></ul><ul><li>Minden statikus tartalom utolsó fájlmódosítási dátum alapján kap verziót </li></ul><ul><li>Css fájlokba injektáljuk a verziókat </li></ul><ul><li>Statikus tartalmat nagyrészét nginx/cdn szolgálja ki </li></ul>
    29. 29. PHP osztályok csomagolása <ul><li>Saját framework osztályok </li></ul><ul><li>Leggyakrabban használt üzleti logikát megvalósító osztályok </li></ul><ul><li>Összeállítása kézzel történik (érdemes lenne rendszeresen monitorozni a hatékonyságot) </li></ul><ul><li>Mérete: ~1Mb jelenleg </li></ul>
    30. 30. Release management
    31. 31. Release management <ul><li>A jó folyamat kiválasztása erősen termék és cégfüggő </li></ul><ul><li>Igazodnia kell a megrendelők (termékmenedzserek) igényeihez </li></ul><ul><li>Ustream: számos azonnali módosítás és gyorsjavítás – be kell tudni illeszteni a napi folyamatokba </li></ul>
    32. 32. Régi út <ul><li>Minden fejlesztés és tesztelés a trunkban </li></ul><ul><li>Élesítés közvetlenül a stagebe </li></ul><ul><ul><li>Lassú élesítés </li></ul></ul><ul><ul><li>Nehézkes a visszahúzás </li></ul></ul><ul><ul><li>Trunk/stage környezet eltérése miatt gyakori hibák </li></ul></ul><ul><li>Trunkban rengeteg halott kód gyűlt fel, egyre nehezebb a karbantartás </li></ul>
    33. 33. Brancheljünk? <ul><li>Fő ág a stage/master branch </li></ul><ul><li>Minden branch a fő ágból ágazik el </li></ul><ul><li>Feature branchek a fejlesztéshez, elsőkörös QA-hoz </li></ul><ul><li>Release branchek az élesítés előkészítéséhez, végleges QA-hoz </li></ul><ul><li>Élesítés csak a release branch váltását jelenti, könnyű visszavonás </li></ul>
    34. 34. Feature branchek <ul><li>Minden fejlesztés kisebb-nagyobb feature és csapat branchekben folyik </li></ul><ul><li>Csapat branchek főleg demózáshoz, komponensek összeillesztéséhez, de rövid időn belül halott kódot tartalmazhatnak </li></ul><ul><li>A termékmenedzserek felől érkező állandóan változó igények miatt nehéz a brancheket karbantartani </li></ul>
    35. 35. Fokozatos refactoring <ul><li>Branchelés helyett refaktorizálás a fő ágban közvetlenül </li></ul><ul><ul><li>Adott komponensben új absztrakciós réteg bevezetése </li></ul></ul><ul><ul><li>Új üzleti logika megvalósítása </li></ul></ul><ul><ul><li>Fokozatos átállás az új megvalósításra </li></ul></ul><ul><ul><li>Ha a régi kódokat már semmi nem használja, az absztrakciós réteg megszüntethető </li></ul></ul>
    36. 36. Élesítés folyamata <ul><li>Release branch létrehozása (nem tag!) </li></ul><ul><ul><li>Tesztelés minél közelebb az éles rendszerhez </li></ul></ul><ul><li>Éles release branch váltás: </li></ul><ul><ul><li>Nincs kiemelt esemény abban az időszakban (pl. sokezer dolláros ppv adás) </li></ul></ul><ul><ul><li>CI buildek hiba nélkül futnak </li></ul></ul><ul><ul><li>QA-n átment </li></ul></ul><ul><ul><li>Szükség esetén sysop/backend csapat review </li></ul></ul><ul><li>Live váltás/rollback egy kattintás </li></ul>
    37. 37. Élesítések ütemezése <ul><li>SCM felületen a csapatok előre felviszik az élesítési időpontokat </li></ul><ul><li>Scrum szerint dolgozó csapatok a sprintek szerint release-elnek </li></ul><ul><li>Pl. backend csapat fix heti release-eket csinál </li></ul><ul><li>Fontos módosítás esetén quickfix release/élesbe kommitolás engedélyezett </li></ul>
    38. 38. Élesítés naptár
    39. 39. Continuous integration <ul><li>Különálló Jenkins szerver </li></ul><ul><ul><li>Repository mirrorból dolgozik (gyors) </li></ul></ul><ul><ul><li>Branchenként külön jobok </li></ul></ul><ul><ul><li>Unit/db/integrációs/end-to-end tesztek futtatása minden kommit után (gyors) </li></ul></ul><ul><ul><li>Nightly build: code coverage, statikus analízis futtatás (lassú) </li></ul></ul><ul><ul><li>Párhuzamos buildek futattása izoláltan (saját db, memcache pooling) </li></ul></ul>
    40. 40. Továbbfejlesztési irányok <ul><li>Jelenleg sok adminisztrációs munka </li></ul><ul><ul><li>Release log karbantartása (JIRA ticketek alapján kigyűjthető) </li></ul></ul><ul><li>Pre-commit/release hook </li></ul><ul><ul><li>JIRA ticketek ellenőrzése </li></ul></ul><ul><ul><li>Phpcs futtatás változott fájlokra </li></ul></ul><ul><li>Release folyamat jobbá tétele, folyamatos kód integráció </li></ul>
    41. 41. KÖSZÖNÖM A FIGYELMET! <ul><li>Jöhetnek a kérdések. </li></ul>

    ×