PHP deployment, environment - best practise

Fejlesztés

Egy kreatív studiónál dolgozok fejlesztőként, ahol szeretnénk gatyába rázni a deploy folyamatokat, valamint ehhez kapcsolódóan bevezetni egy hatékony fejlesztési környezetet, workflow-t. Ehhez kérem a segítségeteket.

Ahogy dolgozunk:

  • A fejlesztők saját munkaállomáson fejlesztenek Debian, illetve Ubuntu alatt.
  • A webszervereken Debian van
  • A grafikusok, sitebuilderek Windowson, valamint Mac-en dolgoznak.
  • A fejlesztések főként PHP-ben, kisebb részben Java-ban folynak.
  • PHP-re egyrészt Drupált, másodrészt Zend FW + Doctrine kombót használunk.
  • Adatbázis PostgreSQL vagy MySQL
  • Verziókövetésre SVN-t használunk, többen szorgalmazzuk a Git-re való áttérést.
  • Unit-teszteket használunk (egyre többet)
  • A projektek mérete eléggé változatos, vannak microsite-ok és vannak nagy szoftverfejlesztések

Igények:

  • Szeretnénk automatizálni a tesztfuttatásokat egy CI szerver segítségével (pl Hudson - Jenkins)
  • A sitebuilderek, grafikusok ne a test szerveren dolgozzanak, mert egyrészt az elvileg az ügyfélnek van, másrészt összekavarodnak a munkáik.
  • Az előbbi két csoportnak viszont ne kelljen lokálisan egy WAMP-ot, MAMP-ot telepíteni és beállítani mindent, hogy dolgozni tudjanak.
  • Szeretnénk a redmine-t bevezetni, jelenleg teszteljük
  • Rengeteg idő megy el mind a teszt, mind az éles szerveren a megfelelő környezet kialakítására úgy, mint:
    • DNS bejegyzés létrehozása
    • Adatbázis létrehozása (test környezetben ez a webszerveren van, éles környezetben van külön DB szerver)
    • chown futtatás svn checkout után (erre minden svn update után szükség van)
    • Összességében fájlrendszer jogosultságok ellenőrzése
    • Doctrine és ZF verziók ellenőrzése, azok checkoutolása, updatelése
    • Ritkább esetben egy-két további függőség telepítése, ellenőrzése: gearman, memcache, APC

Lehet, hogy írok még hozzá, jelenleg ennyi jutott eszembe.

  • 2150 megtekintés

( s_balazs | 2011. 02. 07., h – 21:28 )

hali,
szerintem CI szervernek nezzetek meg ezt is: http://phpundercontrol.org

mi is meg csak szemezgetunk vele - egyelore tapasztalatok hijjan vagyunk. az utolso pontban felsorolt igenyeid szinte mindegyikere megoldas lehet, habar kavet ez sem foz. :)
szerintem kb ennyit minimum ki tudtok hozni belole:
- unit tesztek futtatasa + riasztas
- kodolasi konvenciok betartasanak ellenorzese
- ures adatbazis letrehozasa sema alapjan
- fajlokon jogosultsag kezeles
- 3rd-party cuccok ellenorzese/letoltese/frissitese
- fajlok becsomagolasa, szerverekre kidisztributalasa
meg millio+1 dolog, ami ant build szkripttel automatizalhato.
persze mindezeket barmelyik CI megoldas nyujtja, csak gondoltam ha mar PHP, akkor ezt lehet, hogy erdemesebb... :think:

azt hogy erted, hogy a sitebuilderek es a grafikusok a teszt szerveren dolgoznak? oda mentik a nap vegen munkajukat?

udv, sbalazs.

Köszi, kb 1 évvel ezelőtt rátaláltam, nézegettük, de nem volt elhatározás a vezetőség részéről és a bevezetése elmaradt. Azóta megtaláltuk a Hudsont és az tényleg jobbnak tűnik. Ráadásul java-s projekteket is alá tolhatunk.

A sitebuilderek és grafikusok egy szerveren dolgoznak, vagyis egy working copyn. Ritkán van az, hogy egy projekten több grafikus/sitebuilder dolgozik, de ha előfordul, az nagy problémákat okoz. A working copy egyébként sambán van felcsatolva náluk. Ebből is vannak problémák: a TortoiseSVN 1.6-os, Ubuntuban szintén 1.6-os kliens van, Lennyn viszont 1.5-ös. Namost ha 1.6-os klienssel belepiszkálnak, akkor onnantól 1.5-ös klienssel nem tudok azzal a working copyval semmit se kezdeni (client is too old). És ez elég problémás tud lenni egy teszt szerveren. Vicces megoldás, hogy sambán mountolom a teszt szervert és a saját 1.6-os kliensemmel már nyomhatom a commitot/akármit.

( h040091 | 2011. 02. 07., h – 21:50 )

Ha a fejlesztők/sitebuilderek/grafikusok mellett az ügyfél is tesztel, akkor szerintem nem kerülhető el a projektenkénti 2+ tesztszerver (konkrét esetben 1 fejlesztői, 1 ügyfél teszt, 1+ sitebuilder/grafikus teszt).

Nálunk ezek virtuális gépekkel vannak megoldva, az ügyfél tesztszervere a lehető legközelebb áll az éles architektúrához, a fejlesztői teszt inkább kényelmes tesztelést biztosít.

A környezet kialakításához szükséges időt lehet csökkenteni:
- előre elkészített vm image-ekkel, amik már tartalmazzák a LAMP környezetet is, illetve a céges policy alapján az alapokat
- előre elkészített sql/bash scriptekkel

A különböző környezetekre telepítendő csomag összeállítására, telepítés előtti teendők végrehajtására (build, deploy) érdemes lehet Ant-ot, Maven-t használni. Hudson tudja futtatni ezeket is (de nyilván nem csak a Hudson).

Unit tesztek mellé egyéb tesztelőeszközökkel is érdemes lehet megismerkedni (pl. Selenium)

Nagyjából ennyit tudok hirtelen hozzászólni, remélem segített.

Köszi a tippet, ismerem a Seleniumot, egy kis projektnél alkalmaztam is, de az, hogy Selenium szervereket állítsunk csatasorba, szerintem odébb van. Én pezsgőt bontanék, ha csak a fenti problémákra is megoldást találnánk.

Virtualizált megoldás szintén felmerült (azt is én javasoltam), de sajnos elég kevés tapasztalatom van ezzel. Persze bármikor belövök egy VirtualBox vagy VmWare imaget, de szerveren Xen-t használunk, amivel 0 tapasztalatom van. Így nem tudom, hogy lehetne ezt megvalósítani. Ráadásul nem minden workstation alkalmas arra, hogy photoshop, dreamweaver, firefox, stb. mellett még virtualizáljon is. Vagy nem tudom, te hogy gondoltad a userenkénti working copy és a vm imagek használatát. Ezt ki tudnád fejteni?
A fejlesztők - köztük én is - pedig sokkal szívesebben fejlesztek "host" gépen, mint virtualizáltan, mert megtehetem, értek hozzá, de ha azt mondom egy grafikusnak, hogy telepítsen fel apacheot, mysql-t, hozzon létre vhostot, stb, égnek áll a haja.

Megpróbálom kifejteni, ám csak arról tudok nyilatkozni, amit eddigi munkahelyeimen tapasztaltam, biztos lehet máshogy is :)

A fejlesztő a saját munkáját localhost-on teszteli, tehát oda beállít egy működő környezetet. Ez a folyamat több alrendszerből álló/elosztott rendszereknél valóban bonyolult lehet, cserébe gyorsan meg lehet nézni a munka során, hogy mit sikerült összehozni. Nyilván akkor éri meg ezzel szenvedni, ha a fejlesztés aránylag hosszú ideig tart.

A céges teszt szerverek VMWare-ben futó virtuális gépek, egy komolyabb vason 10-15 VM is akár, ami nem kell, az nincs elindítva. Maga a fejlesztés nálunk sem vm-en folyik, viszont a tesztelőnek Hudson-ból buildelünk egy verziót a megfelelő vm-re, amit nyomogathat. Az utóbbi időben amazon ec2 + dyndns tesztszervereket is használtuk, nagyon költséghatékonyak.

Nálunk a sitebuilder/grafikus statikus html-t állít össze, ezt a fejlesztők szabdalják fel, és írják át a megfelelő részeket dinamikusra. Ebből adódóan a grafikus gépén nincs szükség apache-ra, mysql-re, szerintem.

Remélem sikerült érthetőbben leírni.

Szerk: Ami most esett le nekem: az esetek 99%-ában szerintem nem működőképes dolog, ha a verziókezelőben tárolt struktúrára rá akarjuk erőltetni a deploy struktúrát. Ha emiatt kell svn update a teszt szerveren, akkor ezt kiküszöbölhetitek úgy, hogy az svn update után Ant vagy Maven script-tel állítjátok elő a deploy-olni kívánt csomagot, ami a különböző környezetek esetén valószínűleg eltérő tartalmú lesz. A Hudson erre a feladatra is jó eszköz, tud VCS-ből update-elni/checkout-olni, majd meghívni egy (Ant vagy akármilyen) scriptet, ftp-zni, Tomcat deployt csinálni, stb.

A fejlesztések elején természetesen nálunk is statikus oldalakat gyártanak a sitebuilderek. Azonban amint megkezdődik a programozás, úgy már egy működő, dinamikus oldalakat pofozgatnak, bugokat javítanak. Másrészt a Drupal fejlesztéseknél legjobb tudomásom szerint lehetetlen úgy elkészíteni a html-t, hogy nincs mögötte a motor. Tehát úgy látom, hogy a mi sitebuildereinknek mégis csak kell valamilyen megoldás a PHP futtatásra. Erre láttam már olyan megoldást, hogy egy szerveren mindenkinek volt home foldere, azt felmountolta sambán, és az ott tudott dolgozni. De egyrészt az se volt teljesen automatikus, másrészt jogosultsági problémák voltak állandóan.

A deployolni kívánt csomagok minden környezetben megegyeznek, ugyanis a config fájlok környezetenként vannak definiálva (pontosabban származtatva egymásból). Egy dologra van szükség, egy - mondjuk - vhost fájlban beállított környezeti változóra, ami megmondja a használni kívánt environmentet (production, testing, development).

Production környezetben is virtuális gépeket használtok? Ez nálunk azért lehet problémás (vagy csak én látom annak), mert nem csak nagy projektjeink vannak. Minden kis szir-szar micrositera pedig nem lenne takarékos dolog különálló vm-et futtatni.

Ti ezt a megoldást PHP-re használjátok?

Ebben az esetben én nem látom elkerülhetőnek a lokális *AMP-ot minden workstation-ön, grafikus/sitebuilder esetén lehet közös DBMS.

Nálunk van egy Hudson build szerver, minden projekthez tartozik környezetenként egy job, a Hudson végzi a VCS checkout-ot/update-et, a build-et, a tesztelést, és feltölti a megfelelő szerverre a szükséges fájlokat, esetleg ott is lefuttat egy scriptet. A folyamat során előálló fájlok nagyrészt megegyeznek, de több olyan fájl is lehet, ami különbözik környezetenként (pl. WSDL-ek, egyéb konfig fájlok, template-ek, stb., ezt mi nem tudjuk 1 környezeti változóval lekezelni).

Használunk éles környezetben is virtuális gépeket, microsite esetén természetesen az apache virtualhost takarékosabb megoldás, ha nincs mondjuk PHP ENV változó konflikus, vagy hasonló probléma.

Elsődlegesen Java fejlesztés zajlik nálunk, így természetesen ez nektek nem biztos, hogy optimális megoldás.

( Tyra3l | 2011. 02. 07., h – 22:10 )

"Szeretnénk automatizálni a tesztfuttatásokat egy CI szerver segítségével (pl Hudson - Jenkins)"
Jenkins jo valasztas, jelenlegi felhozatalbol a legjobb(mind PHP-t, mind Java-t tekintve), aktivan fejlesztik, es Sebastian Bergmann is ezt hasznalja, szoval a legtobb php QA tool ezzel van legjobban osszereszelve (najo, a PMD, xUnit, etc. szabvanyos dolgok szoval CruiseControl-ba is belohetok, de imho nagyobb szopas volt CruiseControl/PHPUnderControl ala beconfolni mindent, mint Hudson ala)

"A sitebuilderek, grafikusok ne a test szerveren dolgozzanak, mert egyrészt az elvileg az ügyfélnek van, másrészt összekavarodnak a munkáik."
ezt nem ertem, kifejtened?

"Az előbbi két csoportnak viszont ne kelljen lokálisan egy WAMP-ot, MAMP-ot telepíteni és beállítani mindent, hogy dolgozni tudjanak."
akkor ezek szerint nekik is kell egy linuxos box.
amugy is javasolnam, hogy a sajat desktopos bohockodas helyett virtualizacioval oldjatok meg a dolgozoknak a boxokat, igy konnyeden lehet provizionalni ha uj gepekre van szukseg, es jobban menedzselheto, hogy mindenkinel azonos verziok legyenek, etc.

"Szeretnénk a redmine-t bevezetni, jelenleg teszteljük"
Redmine jo, esetleg erdemes lehet a ChiliProjectet is megfontolni, bar meg eleg "forro" :)
https://www.chiliproject.org/projects/chiliproject/wiki/Why_Fork

"Rengeteg idő megy el mind a teszt, mind az éles szerveren a megfelelő környezet kialakítására úgy, mint"
tessek automatizalni, virtualizacio itt is segithet

"DNS bejegyzés létrehozása"
mondjuk PowerDNS mysql/ldap backenddel, egyszeruen scriptelheto az uj rekodrok felvetele

"Adatbázis létrehozása (test környezetben ez a webszerveren van, éles környezetben van külön DB szerver)"
kicsit tagabb ertelemben veve erdemes lenne a folytonos adatbazis integraciot (continuous database integration) bevezetni:

http://dbdeploy.com/
https://github.com/djk412/mysql-php-migrations

"chown futtatás svn checkout után (erre minden svn update után szükség van)"
erre miert van szukseg? amugy post-commit hook, vagy a deploy folyamatban automatizalhato

"Összességében fájlrendszer jogosultságok ellenőrzése"
marmint inkabb beallitasa, nem?

"Doctrine és ZF verziók ellenőrzése, azok checkoutolása, updatelése"
ezt nem feltetlenul automatizalnam, eltorheti a kodot, viszont azt erdemes lehet scriptelni, amit fentebb is irtam, hogy a kulonbozo kornyezetekben azonos verzioju komponensek legyenek.

"Ritkább esetben egy-két további függőség telepítése, ellenőrzése: gearman, memcache, APC"
ez mar megint a kozponti konfig/szoftver menedzsment iranyaba mutat.

Tyrael

Köszi neked is.

A sitebuilderes dolgot úgy tűnik nem fogalmaztam meg jól, itt leírtam: http://hup.hu/node/98988#comment-1218290
Még annyit teszek hozzá, hogy az, hogy az ő working copyjuk egyben a teszt verzió is, az persze a másik nagy probléma, de ez nyilván megoldható. A kérdés inkább az, hogy legyen mindegyiknek saját példánya úgy, hogy ne kelljen nekik WAMP-ot adminisztrálniuk.

PowerDNS-t használunk mysql backenddel. Az eszköz tehát megvan, de amíg nincs egy normális workflow, addig nem tudjuk megírni a megfelelő scripteket :)

A continuous database integration linkeket köszi, épp, hogy csak hallottam róluk, utána fogok nézni. Mivel lassan-lassan talán át fogunk térni Doctrine 2-re (ami a projektek 80%-át érinti), az abban lévő migration tool használata is felvetődött bennem, nagyon jónak tűnik. Viszont az a maradék 20%-ban (Java és Drupal) nem használható.

A chown-ra azért van szükség, mert SSH-n updatelem a working copyt a szerveren, akkor adott esetben az apache számára nem lesz írhatók egyes könyvtárak. Az apache nobody.nogroup-pal fut általában. Ebben nem vagyok túl járatos, nem tudom, hogy lehetne ezt megoldani, de való igaz, hogy én is ütöm a fejemet a falba, hogy mindig észben kell tartani és ha elfelejtem, akkor jönnek a nem írható log könyvtár kivételek, stb.

( gergoerdosi | 2011. 02. 07., h – 22:21 )

"A sitebuilderek, grafikusok ne a test szerveren dolgozzanak, mert egyrészt az elvileg az ügyfélnek van, másrészt összekavarodnak a munkáik."

A megoldást már leírtad, ne ott dolgozzanak. :) Mi három szerverrel dolgozunk projektenként: production, staging és development. A production az éles oldalt szolgálja ki. A staging szerveren lévő kód az, amit az ügyfél tesztel, mielőtt azt átvinnénk a production-ra. A development szerver pedig a fejlesztőké, azt csinálnak rajta amit akarnak.