ugrás a tartalomhoz

Automatikus kódkezelés a teszt és az élő weboldal között

blackcoffee · 2013. Szep. 26. (Cs), 11.12
Sziasztok,

Szeretnék kérni egy pár tanácsot és útbaigazítást az alábbi problémára:

Van egy élő weboldal és ennek egy másolata a localhoston. A fejlesztés offline
megy, majd tesztelés után felmásolom a modosított fájlokat a szerverre és
tesztelek újból mindent.
A probléma hogy szinte lehetetlen egy az egyben ugyanazt a környezetet kialakítani(php, mysql, apache beállítások, verzió eltérések)
az online és offline szerveren,ezért előfordulhat hogy ami működött localhoston az nem működok online. Ráadásul ugye az is megtörténhet hogy nem veszünk észre egy hibát, csak akkor amikor már élesben van a kód.

Ezért szeretnék létrehozni egy másolatát a weboldalnak az online szerveren, ami
tesztelésre használnék. A munkamenetet így képzeltem el:

1. fejlesztés es tesztelés localhoston
2. a modosított fájlokat felmásolnám az online teszt oldalra es jönne tesztelés újra
3. ha minden ok, akkor a modosított fájlok átkerülnének az élő oldalra

Az online szerver Linux, PHP, Mysql és Apache, a localhost Windows 7, Apache, Mysql és PHP.

Melyik forráskód kezelő rendszer lenne a legalkalmasabb erre a feladatra?
Rengeteg leírás és tutorial van a neten verziókezelő rendszerekről de mégsem sikerült
megtalálnom a helyes utat a problémám megoldása felé.

Bármilyen tanácsot nagyon szívesen fogadok.
 
1

Mi az, amihez eszközt keresel

Joó Ádám · 2013. Szep. 26. (Cs), 11.28
Mi az, amihez eszközt keresel ezen a folyamaton belül? A módosított fájlok másolására az rsync ideális.
2

Köszi, rsync-et megnézem. A

blackcoffee · 2013. Szep. 26. (Cs), 11.42
Köszi, rsync-et megnézem.

A kód módosítások nyilvántartására és a másoláshoz keresek egy eszközt.
A kódkezelést ugye megoldaná egy forráskód kezelo rendszer(svn), de hogyan tudnám ezt
összekombinálni a másolással, hogy ne kelljen kézzel átmásolni 25 fájlt a teszt szerverről az élesre, és probléma esetén egy kattintással visszaállítani a régi verzióra?
3

hogyan tudnám ezt

Joó Ádám · 2013. Szep. 26. (Cs), 11.52
hogyan tudnám ezt összekombinálni a másolással, hogy ne kelljen kézzel átmásolni 25 fájlt a teszt szerverről az élesre, és probléma esetén egy kattintással visszaállítani a régi verzióra?


Egy verziókezelő ezt mind tudja, olvass utána a Gitnek.
5

Gondoltam hogy tudják ezt a

blackcoffee · 2013. Szep. 26. (Cs), 11.56
Gondoltam hogy tudják ezt a verziókezelők, csak eddig nem foglalkoztam alap verziókezelésnél bonyolultabb dolgokkal.
Köszi, bele fogok mélyedni a gitbe.
4

Most találtam ezt a

blackcoffee · 2013. Szep. 26. (Cs), 11.53
Most találtam ezt a bejegyzést, én is ilyesmit akarok mint a kérdező, csak neki talán
sikerült jobban megfogalmaznia :)

how-should-i-move-my-code-from-dev-to-production
6

A probléma hogy szinte

Hidvégi Gábor · 2013. Szep. 26. (Cs), 12.14
A probléma hogy szinte lehetetlen egy az egyben ugyanazt a környezetet kialakítani(php, mysql, apache beállítások, verzió eltérések) az online és offline szerveren,ezért előfordulhat hogy ami működött localhoston az nem működok online.
1, Meg kell szabadulni a verziófüggő kódoktól, át kell nézni a két verzió dokumentációját, és olyan formára kell hozni a programot, hogy mindkét helyen ugyanúgy fusson.

Nem szabad az újabb verziók featúráit használni addig, amíg a verzió ki nem forrta magát, és megjelenik beépítve a különböző linuxdisztribúciókba. Lehet, hogy roppant kényelmes az új PHP-ban tömböt JS-szerűen szögletes zárójelekkel létrehozni, de a rendszergazda mondhatja bármikor, hogy biztonsági okokból visszatértek a disztribúció által hivatalosan támogatott korábbi változathoz, amihez biztonsági javítások érkeznek folyamatosan, míg a legújabbhoz nem feltétlenül.

2, Az általad felsorolt szoftvereknek vannak korábbi verziói, így nem igazán nehéz összehozni Windowson is ugyanazt a környezetet, mint Linuxon. A webszervernél szerintem a verzió sem számít, az eddigi tapasztalataim szerint legalábbis az 1.3-as Apache pont ugyanolyan jól szolgál ki mindent, mint a 2.4-es.
7

Apache nem teljesen ugyan az azért

pp · 2013. Szep. 26. (Cs), 12.43
Rewrite rule-okban azért vannak különbségek.
13

Config

janoszen · 2013. Szep. 26. (Cs), 19.27
Az elég baj! A cél az, hogy kizárólag az alkalmazásod configjában legyen különbség, ugyanis így minimalizálod a hibalehetőségeket. Esetleg 1-2 setenv, hogy az alkalmazád tudja hol fut, de rewrite különbség ne legyen! Szoftververzióban, oprendszerben pláne nem, mert akkor jönnek a meglepetések.
14

Szerintem pp az 1.3-as és

Joó Ádám · 2013. Szep. 26. (Cs), 19.39
Szerintem pp az 1.3-as és 2.4-es Apache különbségeiről beszélt.
18

Nem jogos

janoszen · 2013. Szep. 27. (P), 08.37
OK, de eleve nem jogos, hogy a teszt es eles kornyezetben mas Apache fusson. Webfejleszto meg ne mondja nekem, hogy nem boldogul el egy kattingatos linuxszal mert az kb olyan, mintha azt mondana, hogy nem tud doksiolvasasi szinten angolul. (Mar persze ha Linuxra fejleszt, ami itt ugye nyilvanvaloan fennall.)
16

Köszi a részletes

blackcoffee · 2013. Szep. 26. (Cs), 22.36
Köszi a részletes választ.
Ezekre mindig torekszem, de sokszor viszont gányolt, régi, spagetti kódot kell
tovább fejleszteni vagy boviteni.
8

capistrano

Greg · 2013. Szep. 26. (Cs), 12.44
Neked egy deploy megoldasra van szukseged ha jol ertelmezem. A capistrano erre tokeletes. Itt egy parancs kiadasaval vissza tudod allitani az elozo allapotot ha problema merul fel. Akar azt is meg tudod csinalni, hogy mielott elesiteni a frissitest lefuttatja a teszteket es hiba eseten nem elesit.
http://www.capistranorb.com/
12

+1

tgr · 2013. Szep. 26. (Cs), 18.59
deploy / deployscript / deploy tool kulcsszóra keresve találhatsz ezzel kapcsolatos eszközöket. Pl. a Phing tud rsync-en, FTP-n vagy SSH-n át feltölteni fájlokat, vagy használhatsz git push hookot, vagy komolyabb IDE-k is tudnak deployolni.
9

Ami a hasonló környezet

bamegakapa · 2013. Szep. 26. (Cs), 13.04
Ami a hasonló környezet kialakítását illeti, lehetőséged van létrehozni egy virtuális gépet és arra klónozni az éles szerver rendszerét. Vagy felépíteni egy nagyon hasonlót. Ahogy Gábor is mondja, érdemes törekedni rá azért, hogy minimalizáld a rendszertől való függést, amennyire ez lehetséges.

Részemről gitet használok verziókezelésre (alkalmas arra is, hogy a dev és a staging szerver között mozgasd a kódot), éles szerverre rsync-el küldöm ki a módosításokat. Elvileg ezt is csinálhatnád persze gittel, pl.:

- A web-focused Git workflow
- git-deploy
- Using Git to manage a web site
10

A virtuális gép jó ötleg, meg

blackcoffee · 2013. Szep. 26. (Cs), 15.27
A virtuális gép jó ötlet, meg is próbálom.
Köszi a linkeket, nagyon jók.
11

Vagrant

Wabbitseason · 2013. Szep. 26. (Cs), 15.44
Virtuális gépek kezeléséhez esetleg érdemes lehet a Vagranttal is megismerkedni:

http://www.vagrantup.com/

http://vimeo.com/64392910
15

Köszi. Ez sokat segít, így el

blackcoffee · 2013. Szep. 26. (Cs), 22.34
Köszi. Ez sokat segít, így el tudok indulni egy irányba már.
17

dev - teszt - éles (néha ki

deejayy · 2013. Szep. 27. (P), 07.53
dev - teszt - éles (néha ki szokás egészíteni plusz egy teszt környezettel), én ezt a módszert ismerem, használom.

Verziókezelésre gitet használok, de a teszt rendszerről az élesre a fájlokat kézzel másolom át - minden változást felügyelni akarok. Ha automatikus deployt használnék, akkor is belépnék ftp-n, hogy lecsekkoljam, jó fájlok mentek-e ki :)

A rendszerek teljesen különbözőek, a dev ugye win7, néha frissítem a legújabb php-re, legújabb apache-ra, teljesen más elérési utak, stb.

A teszt rendszeren megpróbálom leszimulálni az éles környezetét, de nem töröm magam, csak annyira, hogy mondjuk a konfig fájl a legkisebb mértékben térjen el az élestől (de pl. felveszem a hosztingok sql szerverét a 127.0.0.1-re, symlinkek, ha nagyon kell). Próbáltam már szkanderozni egy-két szolgáltatóval, hogy a dev könyvtárstruktúrát tudjam élesben is használni, de általában falakba ütköztem, szóval ezek a keretrendszerben szabadon variálhatók.

Az éles rendszer meg teljesen heterogén, ahány projekt, annyi hoszting, mindegyik más környezetet biztosít.
19

A magam részéről szintén git.

rrd · 2013. Szep. 27. (P), 10.59
A magam részéről szintén git. E mellett ha vannak unit tesztjeid akkor jó eséllyel azok kiszolgálják amit a teszt környezettől várnál.
20

Nagyon szépen köszönöm

blackcoffee · 2013. Szep. 28. (Szo), 00.06
Nagyon szépen köszönöm mindenkinek, sokat segítettetek!