ugrás a tartalomhoz

.svn könyvtárak tiltása Apache webszerveren

EdgarPE · 2008. Júl. 10. (Cs), 10.34
Egy rövid, de hasznos subversion tipp.
 ■
1

Hogy kerül oda .svn?

zila · 2008. Júl. 10. (Cs), 10.55
Végül is kerülő megoldának jó, de szerintem inkább exportálni kell az svn-ből az éles rendszerbe és nem checkout-olni. Máris nem lesznek .svn könyvtárak a webszerveren...
2

rsync akkor már

js · 2008. Júl. 10. (Cs), 11.04
Az export nem rossz, de az nem törli az új verzióban már nem található fájlokat. Én két lépésben csinálnám, egy export (-> /tmp) és egy rsync fázisból (persze az eredeti konfig /tmp-be másolásával). Az tuti működik.
4

Jogos

zila · 2008. Júl. 10. (Cs), 13.58
Na így már tényleg teljesen jó lehet az automatizált deployment :)
Kösz a kiegészítést.
3

co

Őry Máté · 2008. Júl. 10. (Cs), 12.06
Hát igen, az automatizált svn update nagyon buta megoldás. Különösen, ha valami történik a fájlokkal, és frissítéskor becsúszik egy konfliktus. És a fejlesztőnek meg nincs közvetlen hozzáférése a fájlokhoz, csak updateelni tudnak. Hallottam már ilyet.
7

elvileg nem lehet conflict

Hodicska Gergely · 2008. Júl. 10. (Cs), 21.29
A környezetbe ahol delpoyolsz sohasem editálod a fájlokat, mindig csak az SVN-ből megy a változás egy irányban, ezért nem lehet konfliktus. Ami nem hangzott el, és ami miatt szerintem nem jó az svn update az az, hogy pl. az SVN nem tárolja a fájl jogosultásgokat, ezért bármikor becsúszhat egy olyan hiba, hogy elfelejtesz egy könyvtárat írhatóvá tenni stb.

Ezért szerintem a következő lehet egy jó megoldás: először admin gépen SVN update egy working copyra, ezután itt egy szintén az SVN-ben tárolt konfig alapján lefut egy script, ami mondjuk beállítja a jogosultságokat (illetve itt futhat tetszőleges build folyamat, pl. js fájlok tömörítése tényleg bármi), majd ha ez megvan, akkor kiszólunk a szervernek, hogy vigye a stuffot. Ő syncel egyet, majd ha késze van, akkor még ott is lefut egy script. Ennek az lehet az értelme, hogy bizonyos tényeket a szerver tud magáról, például beírja a konfig fájlba a hostnevet, vagy bármi ilyesmi adatot.

Picit még lehet rajta csavarni, pl. ha sok gép van, akkor érdemes lehet két lépcsőben végezni, először minden gép felfrissíti magát, utána pedig végig rohanunk rajta, és átállítjuk a rendszert a kifrissített verzióra (mind az apache-ot mondjuk, mind pedig az opcode cache-t), így viszonylag minimalizálva van az az idő, ameddig a szerverek nincsenek szinkronban.


Üdv,
Felhő
9

Szerver vissza?

janoszen · 2008. Júl. 12. (Szo), 11.47
Csak egy apró kérdés: jó az, ha az éles szerver be tud nyúlni a fejlesztői hálózatba? Inkább fordítva kellene, nem?
10

admin != dev

Hodicska Gergely · 2008. Júl. 12. (Szo), 16.19
Az admin gép az nem dev környezet.

Üdv,
Felhő
12

Hát?

janoszen · 2008. Júl. 12. (Szo), 18.39
Hanem egy olyan gép, amelyiken az éles környezet repója lakik? Miért jobb a pull mint a push módszer?
14

kb.

Hodicska Gergely · 2008. Júl. 12. (Szo), 19.13
Ez is része az éles rendszernek, pl. ezen futhatnak olyan cronok, amik nem gép specifikusak, hanem a teljes rendszerre vonatkoznak. Alapvetően szerintem mindegy hogy push vagy poll.


Üdv,
Felhő
15

Vis maior

Őry Máté · 2008. Júl. 13. (V), 11.25
Kivéve, ha valaki véletlenül belejavít, majd elutazik. Vagy megáll a szkript, és. Vagy.
16

emberi hülyeség ellen nincs orvosság

Hodicska Gergely · 2008. Júl. 13. (V), 12.12
Kivéve, ha valaki véletlenül belejavít, majd elutazik.
Ha nem utazik el, akkor is conflict lesz. ;)

Vagy megáll a szkript, és. Vagy.
Persze, nem a legszofisztikáltabb megoldás, nem is ez lenne az ajánlott, a conflict részre reagáltam.


Üdv,
Felhő
5

Dev környezet-ben

EdgarPE · 2008. Júl. 10. (Cs), 18.14
Én úgy csinálom, hogy van egy DEV környezet, itt dolgozom a fájlokon. Ezt verziókezelem, ezért vannak itt .svn könyvtárak. Viszont a DEV környezetet nem csak én látom, hanem a megrendelők is, illetve akinek a megrendelő odaadja a jelszót. Ez néha elég messzire el tud gyűrűzni, ezért tiltottam le itt az .svn könyvtárak megjelenítését.
6

erre nem gondoltam

Őry Máté · 2008. Júl. 10. (Cs), 20.41
Én jobb szeretek a saját gépemen dolgozni.
8

Nem tennék ilyet

janoszen · 2008. Júl. 12. (Szo), 11.41
Nem tennék ilyet, több okból sem. Egyrészt a trunkba néha nőnek olyan dolgok, amik inkonzisztenssé teszik az aktuális állapotot vagy ne adj isten, szétbarmolják az adatbázist, ha bizonyos funkciókat használsz. Ergó ha a megrendelő pont akkor nézi meg, akkor lehet hogy nem lesz túl boldog. Főképp a projekt vége fele, amikor már mindennek stabilnak kellene lennie és talán pont mégsem az, viszont commitolsz egyet, mert éppen befejezed a munkát.

A dolog egy fokkal jobb, ha a stable branchet / taget veszed ki, mert akkor ilyesmi nem fordulhat elő, de még mindig fennáll az a tény, hogy a projekt viszonylag késői fázisában lesznek látványosak az eredmények, ergó a megrendelő nem lesz túl boldog, ha a tárhelyen hosszú ideig egy szétesett, nem működő változatot lát.

Arról nem is beszélve, hogy deploymentkor illik még néhány dolgot megcsinálni (ezek egy része a teszt tárhelynél kiesik) aminek semmi köze nincs a fejlesztéshez. Én pl már a tesztszerverre küldéskor előállítok a CSS és JS fájlokból egy tömörített, gzipelt változatot, generálok autoload indexet, állítok be jogosultságokat és nem utolsó sorban ez a shell script teszi ki a deployment előtt az 503 karbantartás alatt című lapot és teszi vissza, ha végzett.
11

rekontra

js · 2008. Júl. 12. (Szo), 16.31
ClearCase adminisztrátorként úgy érzem, "kötelességem" felszólalni a trunk ellen. Sajnos nem sok alternatív lehetőséget mutatnak be a jól bevált rendszerek, és mind a mai napig képesek fejlesztőcsapatok egy közös trunk-ot használni. Csak referenciaként, az ilyet "gettó" modellként emlegetik, lévén ha ki tudja onnan verekednie magát egy változtatás, az vagy nagyon jó, vagy hozza az egész bandát.

A development branch-et azt mindenki saját magának csinálja, esetleg az integrációs branch-et mutatja meg az ügyfélnek (azaz rakja staging szerverre). Ott már valószínűbb, hogy kisebbek a hullámok. A tesztelt, elfogadott verziót meg az élesre teszi.

Maga a deployment is egy teljesen automatizált dolog kell legyen (vö. capistrano), tehát az ottani cuccokba fel sem merül, hogy piszkálunk. Az automatizálásba tényleg nagyon sok mindennek benne kell lennie (vagy legalábbis érdemes), de ugyanennyire igaz az is, hogy az eredeti cikk meg sem próbálja az egészet deployment-nek hívni. Az ott inkább egy kis könnyebbség az embereknek, még jóval a baltás processz előtt.
13

Mindenki a maga követelményeinek megfelelően

janoszen · 2008. Júl. 12. (Szo), 18.46
Mindenki a maga követelményeinek megfelelően. Mi most konkrétan egy elég kis csapat vagyunk és nekem kell ellátni a rendszergazdai feladatokat is, ergó egy shell script megírása egyszerűbb volt a konkrét feladatra, mint erölködni valamilyen rendszerrel. Nyilván, csak itt működik, de legalább automatizált.

Illetve, nem is egészen, mert az adatbázisra még mindig nem találtam megnyugtató módszert, mint hogy kiindulunk egy alap create scriptből aztán írjuk hozzá az alter table-eket. Ezek lefuttatására viszont még nem írtam meg a tudományt.

Lényeg amit mondani akartam, hogy egy kis létszámú csapatnál (ne adj isten egy embernél) több fajlagos overheadet jelent a branchek menedzselése, mint egy nagy csapatnál, ezért nem is biztos, hogy érdemes erölködni a mainstream funkciók fejlesztésénél. Az mondjuk nem kizárt, hogy azért mondom ezt, mert senki nem mutatott még eddig egy jól megszervezett munkastruktúrát. (Erről valaki, aki már látott ilyet, megejthetne egy cikket.)

(Időközben egyébként kiváncsi lennék a post írójának struktúrájára is.)
17

dvcs

js · 2008. Júl. 13. (V), 21.14
Akármilyen kicsi a csapat, mindenképpen a disztributált verziókövető rendszert javaslom, és legyen egy "főnök", aki eldönti, hogy egy változás abban a formában, ahogy van, bekerülhet-e a szoftverbe, vagy sem (nevezzük integrátornak). Annyi a plusz feladata, hogy figyeli, hogy az előzőleg meghatározott követelményeknek (pl. egy hiba megoldásának, a specinek, a tesztek lefutottak, átment a code review-n, fordul-e a progi, megáldotta-e a pap, akármi). Vannak, akik ezt egészségesen oldják meg: ha elrontod a build-et, akkor addig te csinálod, amíg valaki más nem seszi el.

Deploymentre meg eddig két igazán jól működő módszert láttam: az egyik a capistrano, a másik meg RPM-alapú csomagkészítő virtuális gép, plusz néhány jól megírt cron job, ami az oda ssh-zott csomagot kibontja, és az aktuális verzióra húzza az adatbázis verziót.

Ez utóbbira már-már majdnem jó megoldást nyújt a rails, csak épp arra nem gondoltak, hogy az egészet verziókövetni is kéne, és deploykor le is kéne futnia. Dióhéjban: minden adatbázisváltoztatáshoz van egy upgrade és downgrade szkript, így más verzió deploy-olásakor elvileg lehet upgrade/downgrade-elni. Ez egy fejlesztőnél még talán megy, de ha már ketten akarják módosítani az adatbázist, az már gáz.

Ezt úgy oldottuk meg hajdan, hogy az adatbázis verziót két részre szedtük: production és dev verzióra. A production verzió van kint az élesen, és ahhoz lehet patch-elni a dev verziókkal. A patch-ek majd belekerülhetnek az újabb prod verzióba. Egy verziószám lehet mondjuk 25.0 (25-ös prod), vagy 32.41 (a 32-es prod 41-es dev verziója).

Az upgrade-downgrade egyszerű: csomag levételekor mindig visszatérünk az utolsó production verzióra (azaz az összes dev verziót leszedjük), majd az új csomag felrakásakor először a megfelelő production, majd az utolsó dev verzióra állunk.

Ööö a magyarázás sosem volt erősségem, emészthető volt?