ugrás a tartalomhoz

Webes projekt SVN

janoszen · 2007. Jún. 2. (Szo), 13.24
Sziasztok,

egy olyan kérdésem lenne, hogy egy új projektemhez szeretnék SVN-t használni. Osztott szerveren vagyok, de elvileg föl van telepítve. Lehetséges-e megoldani azt, hogy mondjuk én egy alkönyvtárban (/svn?) lássan az SVN repót, a domain root alatt pedig a head revision muzsikál mint éles verzió?

Köszi

János
‹ VirtualHost a webroot alkönyvtáraiból Apache 2.2.4 + PHP + Rewrite ›
 ■
1

Kicsit off

Max Logan · 2007. Jún. 2. (Szo), 14.25
Pontosan hogyan is működik ez a verziókövetős dolog (mert nekem nagyon nem tiszta)? Egyáltalán ez az SVN, ez mi? Egy program a gépen vagy egy web-es cucc? Hogyan követi a változásokat, nekem kell betenni egy új verziót vagy magától követi le, amikor módosítok vmit egy file-on?

Kutakodtam magyar leírás után, de kevés sikerrel ...
2

Verziókövetés

janoszen · 2007. Jún. 2. (Szo), 14.38
Pontosan arról van szó, hogy ha fejlesztek (pl egy PHP fájlt) akkor az SVN repositoryból "checkoutolom", szerkesztem, aztán "commitolom", azaz visszateszem. Amikor visszateszem, akkor egy új verziót hozok létre, ezáltal ha valamit elbarmolok, vissza tudok állni korábbi verzióra.

A nagy dolog ebben az, hogy pl. az Eclipse alapból kezeli ezeket a dolgokat, ami egyrészt lehetővé teszi a kollaboratív (együttműködő) fejlesztést másrészt meg nem az éles verzióban kell barmolni.

Nekem pontosan ez lenne a cél, hogy a projektemen egyrészt több ember is tudjon fejleszteni másrészt legyen verziókezelve az egész.
3

Már alakul

Max Logan · 2007. Jún. 2. (Szo), 14.50
Már kezdem érteni. Szóval kb. arról van szó, hogy a file-ok változásainak ad egy verziószámot és ha kell a régi, akkor azt elő tudom venni.

Itt az egész project kap verziószámot vagy a file-ok külön-külön?

Igazából engem az érdekelne, hogy ha van egy project, ami kint van élesben és én fejleszteni akarok rajta localhost-on, akkor a verziókövetés révén tudjam, hogy az új verzióhoz milyen file-okat kell feltennem az éles szerverre (pl. csinálok egy új modult az odalhoz, ami áll php, js, css stb. file-okból és ha pl. módosul a lib_general.php-m, akkor azt 2 hét múlva ne felejtsem el felmásolni az éles szerverre, amikor feltszem a kész fejlesztést).
5

Ezt lekezeli az svn

Ajnasz · 2007. Jún. 2. (Szo), 15.32
A verzikezelő rendszer nyilván tartja, hogy melyik fájlok módosultak, le tudod kérdezni azok státuszát, így nagyjából nem tudod elfelejteni feltölteni.
11

SVN esetén globális verzószám van

Hodicska Gergely · 2007. Jún. 2. (Szo), 18.57
Az SVN-ben mindig a teljes repónak van egy verziószáma, illetve SVN zsargon szerint revíziószám. Ez sokkal jobb megoldás is, mint a CVS-nél, ahol minden fájl külön verziószámal rendelkezett.

Amit szeretnél, arra teljesen jó az SVN. Arra érdemes figyelned, hogy érdemes egy tagban "nyilván tartani", hogy melyik verzió van kint az éles szerveren. Ha így jársz el, akkor mindig meg tudod csinálni, hogy ebbe a LIVE tagba teszed be (merge-eled) a LIVE tag és trunk közti különbséget, ami az utolsó élesítés óta történt összes fejlesztést jelenti. De vannak ehhez toolok is, amik megmutatják ezt a különbséget, és vizuálisan el tudod dönteni, hogy a változások közül miket teszel ki élesbe.


Üdv,
Felhő
4

Proba

Protezis · 2007. Jún. 2. (Szo), 14.57
Elvileg igen, gyakorlatilag miert nem probalod ki?
SSH-n hozzafersz a serverhez?
6

Megoldható

janoszen · 2007. Jún. 2. (Szo), 16.59
Megoldható, bár az SSH erősen le van korlátozva, szóval nem tudom, mit tudok futtatni. Az a baj, hogy nem tudom, hogy oldom azt meg, hogy /svn legyen az SVN repo és /-ből szolgálja ki az élest...
7

Én is

Fraki · 2007. Jún. 2. (Szo), 17.02
Szia, én is épp készülök ráállni az SVN-ezésre. Én egyelőre úgy terveztem, hogy az egyes fejlesztők számára külön virtual subdomainek állnak rendelkezésre (dev-joska.domain.com, dev-pista.domain.com stb.), oda checkout-oljanak, fejlesszenek a szerveren, aztán a munkájuk végeztével mondjuk egy bash scripttel commitoljanak + a főszájtot update-eljék (dev.domain.com).

Én egyelőre más lehetőséget nem nagyon látok, mert én lokálban is úgy fejlesztek, hogy vmware-ben fut egy gentoo, és ssh-n csatlakozom rá...

Azt nem tudom, hogy lehet megcsinálni, hogy commit után valahol automatice az update-elt (vagy HEAD) revision muzsikáljon, ha erre van tipp, én is örömmel venném!!!
8

Ezt találtam

Fraki · 2007. Jún. 2. (Szo), 17.11
Utánanéztem, ezt találtam:

http://svn.haxx.se/users/archive-2005-10/0675.shtml
9

Tééényleg

janoszen · 2007. Jún. 2. (Szo), 17.17
Tényleg, hook scriptekkel meg lehetne oldani. Sőt, akkor már az offline devel szerverről is... mondjuk az eredeti kérdésem pont az lenne, hogy élesben az SVN-ből szedje a dolgokat ezzel megspórolva nekem egy kört.
10

simán

Hodicska Gergely · 2007. Jún. 2. (Szo), 18.48
Az SVN-t oda állítod be, ahová csak szeretnéd, én a helyedben ezt nem a sima webroot alá tenném, hanem valamilyen másik portra és https-re. Az éles rendszert megint csak oda teszed ahová csak szeretnéd, a frissítést meg úgy tudod megoldani, hogy a különböző SVN eseményekhez tudsz hook scripteket rendelni. A commit hook scriptjében tudod megtenni pl. azt, hogy a script (először checkoutolja) mindig egy munka könyvtárban updateli az adott SVN ágat, majd mondjuk rsync-kel a megfelelő helyre pakolja. Érdemes a hook scriptet konfigolhatóvá tenni (a konfig lehet maga is az SVN-ben), és pl. tárolhatsz benne olyasmit, hogy mely fájlok könyvtárak esetén kell extra jogokat beállítani (pl. smarty compiled dir stb.), mert ezt az SVN nem tárolja, mely könyvtárak legyenek kihagyva, ilyesmik.

Az SVN-t érdemes úgy kialakítanod, hogy a truk-ban folyik a fejlesztés, és van mondjuk egy LIVE taged, ide kell azt becommitolni, aminek ki kell kerülni az éles rendszerre. Így a trunkban tudtok többen együtt dolgozni, anélkül, hogy egyből kikerülne minden az éles rendszerbe, és akár így az is megoldható, hogy pl. nem mindenkinek van joga kódot élesíteni. Az elég fontos, hogy deploy mechanizmus az programozottan történjen, és a legjobb, hogyha automatikusan vissza lehet állni az előző verzióra. Azt is meg lehet csinálni, hogy pl. a trunk tartalma látható egy test domain alatt, így könnyen lehet élestés előtt tesztelni a kódot.


Üdv,
Felhő
12

Automatizmus

janoszen · 2007. Jún. 2. (Szo), 19.51
Ez jó, csak az automatizmussal akkor van baj, ha az adatbázist is izgatni kell. Ebben az esetben nehézkes így megoldani... vagy erre is van megoldás?

Esetleg van erre (FTP upload) valahol kész hook script?
13

Hook script

janoszen · 2007. Jún. 2. (Szo), 22.13
Na, kicsit utánanéztem. Gyakorlatilag azt lehetne csinálni, hogy egy SVN hook script kicommitolja a lemezre valahova és utána föltölti a szerverre. Sajna nem nagyon van rsync a szerveren és az SSH olyan szinten le van limitálva, hogy nem igazán tudok vele mit kezdeni.
17

kicsit pontatlan

Hodicska Gergely · 2007. Jún. 2. (Szo), 22.39
azt lehetne csinálni, hogy egy SVN hook script kicommitolja a lemezre
A hook script fut le commitkor, abban nem kell commitolnod, meg eleve KIcommitolni nem nagyon lehet. ;)

Egyik megoldás, hogy a hook scriptben tudod, hogy mely fájlok változtak meg, ezeket egyszerűen felftp-zed, persze megspékelve megfelelő hibakezeléssel. Szerintem így érdemes csak megközelíteni, különben ha teljes projektet töltöd fel mindig, akkor egyre lassabb lesz az élesítés.

Másik megoldás, hogy kibulizod az rsyncet. Mit jelent amúgy, hogy az SSH le van limitálva? Az FTP-s megoldással szemben ez lényegesen robosztusabb megoldás, több előnnyel is bír.


Üdv,
Felhő
18

Fáradt vok

janoszen · 2007. Jún. 2. (Szo), 22.41
Bocsi, kicsit fáradt vagyok.

Az rsync nem fut daemonként és SSH-ból csak pár parancsot tudok indítani, annyit tesz.
14

DB verzió követés

Hodicska Gergely · 2007. Jún. 2. (Szo), 22.13
Az adatbázis verzió követése nem egyszerű kérdés. Anno volt róla egy thread a PHP listán. Ezt olvasd át, sok féle megközelítés elhangzott. SQL levlistán is ment róla egy kör. Egy alap megoldás lehet olyasmi, hogy tartod magad ahhoz, hogy minden DB változást úgy hajtasz végre, hogy megírod a szükséges módosító scriptet. Ezeket a patcheket gyűjtüd egy könyvtárban. A patch fájl nevének kell legyen valamilyen struktúrája: valamifajta azonosító, dátum, lehet benne egy rövid szöveges rész, ami utal a változtatásra (könnyen meg lehessen egy adott változtatást találni a fájlok között), valamint egy flag (erről mindjárt később). Az SVN tetszőleges revíziója esetén az adott programkód állapot számára szükséges patch megtalálható ebben a könyvtárban. A flag azt mondja meg, hogy az adott patch része kell-e legyen a rendszernek, ami azért lehet jó, hogy tudj ide olyan scriptet is betenni, amire még nincs szükség. Ha ez így megvan, akkor lehet egy olyan felállás is, hogy a kifrissítő script ha ebben a könyvtárban talál új fájlt, akkor végrehajtja ezt. Itt persze kell figyelni a hibákra, meg ilyesmi, de elég sok esetre kellően jó megoldás lehet. Ami itt pl. para lehet, hogy nem könnyű megoldani, hogy ha visszalépsz verziót, akkor DB szinten is visszalépj, adott esetben ez már lehet, hogy nem is lehetséges. Szóval itt valszeg kompromisszumokat kötve lehet csak jó megoldást találni, de több könyvben is olvastam olyan ajánlást (pl. flickr), hogy DB séma módosítást nem éri meg automatizálni, mert sok nem várt macera léphet fel, jobb kézzel végezni.

Esetleg van erre (FTP upload) valahol kész hook script?
SSH-d nincs? rsync-el jóval hatékonyabban meg lehetne oldani.


Üdv,
Felhő
16

rsync

janoszen · 2007. Jún. 2. (Szo), 22.33
Köszi az infókat, majd kitalálom mi legyen.

rsync sajna nincs, ha lesz akkor is csak reverse (tehát a szerverről az én gépemre); most próbálom kiharcolni.

szerk: Helyesen indulok ki abból a feltételezésből, hogy rendesen megtervezett és normalizált adatbázis esetén nem nagyon van szükség hozzányúlni már meglevő táblaszerkezetekhez?
22

FTP

janoszen · 2007. Jún. 4. (H), 09.26
Na, kerülő úton de megoldottam. Az Eclipse-hez van egy WebDAV és FTP plugin, Team Sync alatt, úgyhogy azzal tudom az éles szerverrel szinkronizálni a dolgokat.
15

egy kis szkriptelés

sotetbarna · 2007. Jún. 2. (Szo), 22.27
Hali!

Nálunk az alábbi szitu van:
- mindenki lokálban fejleszt (lokál webszerveren, apache, php, mysql, eclipse)
- mindeki folyamatosan kommitolja a munkáit, azaz mindekihez eljut a fejlesztés eredmény
- amikor közeledik egy olyan státusz, amikor élesítenénk a kódot, akkor általában körbeteszteljük a kódot, ha kell javítunk stb.
- amikor mindenki bólint, hogy mehet, akkor csinálunk egy exportot az éles könyvtárba a szerveren

Technikailag minden ssh alapon megy, kulcsos authentikációval (mindenkienk saját loginja van a szerverhez, elkülönüljenek az egyes szerkesztők munkái)
a putty és plink segítségével egész jól lehet ezt kezelni, pl. ha exportálni akarunk, akkor elég egy parancsot futtatni a lokál gépen:

plink.exe -load "elmentett putty session" "bin/export_to_webroot"
a bin/export_to_webroot tartalma:

#a biztonság kedvéért egy mentés az éles forráskódjáról
save_php_scripts
#exportálás
svn --force --username xxuserxx --password xxpassxx export xxsvn_forrásxx xxwebrootxx
#tulajdonos átírás a biztonság kedvéért
chown -R xxwebszerver_userxx xxwebrootxx
Az adatbázis frissítésével kapcsolatos kódokat egy fájlban tároljuk, azt manuálisan futtatjuk az exportálással egyidőben.

Az is jó tipp, amit Felhő adott, egyszer azt is kipróbáljuk. :)

Most vezettünk be éppen egy plusz subdomaint, ahol a fejlesztés eredményét lehet követni az egyes éles exportok között, de itt is manuálisan exportálunk. Ez ahhoz kell, hogy azok a kollégák is hozzáférjenek a kódhoz, akiknek nincsen lokál fejlesztőkörnyezete, illetve a levelek feldolgozását is biztosabb a szerveren is tesztelni, nem csak lokálban.

Sőt, a tesztelés és designolás könnyítésére készítettünk egy olyan relatív szabadon másolható csomagot, ami tartalmazza a webszervert, adatbázist és a forráskódot (ebben az esetben tortoise svn-el oldják meg a forráskódok frissességét).

Üdv:

Barna
19

inkozisztencia

Hodicska Gergely · 2007. Jún. 2. (Szo), 23.02
Ebben a megoldásban nekem csak egy dolog tűnik problémásnak, az export ideje alatt inkonzisztens állapotban van a projekt. Ez persze az rsync esetén is így van, de nagyságrendileg kevesebb ideig tart (még a mi terhelésünknél sem jött elő ebből adódó gond, pedig az elég gyakori, hogy olyan frissítés van, ahol az egyik fájlba bekerül egy függvény, a másik meg használja).

Esetlg az pl. lehet egy megoldás, hogy az export megy egy timestamp nevű könyvtárba, majd amikor készen van, akkor a docroot (ami egy symlink az előző export timstemp könyvtárára) átáll az új könyvtárra. Ennek még annyi előnye is van, hogy nagyon egyszerű egy korábbi verzióra visszaállni, ha valami para lenne.


Üdv,
Felhő
20

503

janoszen · 2007. Jún. 2. (Szo), 23.17
Ha van megfelelő mechanizmus, akkor arra az időre 503-as hibát lehet dobni...
21

nem mindig teheted meg

Hodicska Gergely · 2007. Jún. 3. (V), 00.01
Ezt nem teheted meg sok esetben, a szolgáltatásank futnia kell (főleg ha fizetős). És pláne nem teheted meg, ha jobb szervezéssel elkerülhető, hogy leállás legyen.


Üdv,
Felhő