ugrás a tartalomhoz

Laravel egy átlagos tárhelyen

csabessz47 · 2015. Júl. 4. (Szo), 13.31
Sziasztok,

Laravelnél megkerülhetetlennek tűnik a terminál használata.
De átlagos tárhelyeken nem adnak ssh hozzáférést, így az artisan és composer használata ki van zárva.
Hogyan szoktátok ezt áthidalni?
Első ötletem, hogy az egész projektet - még a vendor mappát is - beletenni a verziókezelőbe, és így minden push után tudná deployolni.
Viszont ez elég "fapadnak" tűnik, a sok felesleges fájl miatt is.
Második ötletem, hogy egy php fájlban exec használatával lefuttatni a szükséges parancsokat. De mi van akkor, ha nem engedélyezett?

Ti hogyan szoktátok megoldani?

Köszi előre is válaszokat.
 
1

Nagyon egyszerű, tárhelyet

inf · 2015. Júl. 5. (V), 02.06
Nagyon egyszerű, tárhelyet váltasz. A másik lehetőség, hogy manuálisan próbálkozol megtákolni. Git-nél pl a módosításokat git-ftp-vel fel lehet szórni az adatbázist meg kézzel hozzáigazítod. Nem tesztelhető, ha elrontasz valamit, nincs rollback, stb... Nem éri meg, hacsak nem kis projekt, aminél nincs mit elrontani.
2

Én egy ideje a külső

Joó Ádám · 2015. Júl. 5. (V), 14.24
Én egy ideje a külső könyvtárakat is verziókezelés alá vonom. Fájdalmas tud lenni, amikor néhány évvel később össze kell vadászni egy verziót, ha egyáltalán lehetséges, és nem saját könyvtárról van szó, ami már rég elveszett valahol.

Tehát én az első alternatívát javaslom.
3

Artisan facade

gabesz666 · 2015. Júl. 6. (H), 09.36
Esetleg az Artisan facade segíthet ilyen esetben.
4

még a vendor mappát is -

spapp · 2015. Júl. 6. (H), 10.21
még a vendor mappát is - beletenni a verziókezelőbe

Szerintem ez az egyik legrosszabb ötlet amit elkövethetsz.
Ilyenkor igen nagy a kísértés, hogy a külső libbe valaki "belejavít".
Ami igen sok bosszúságot okozhat. És általában okoz is.


Mi lenne, ha lenne egy teszt szervered.
- mondjuk egy virtuális gépben
- pont olyan, mint a tárhelyed

Te ide deployolnál először.
Itt minden teszt és egyéb dolog jól lefutna...

Ha sikeres, akkor az éles környezetbe már csak ftp-vel fel tolod a letesztelt kódot.
5

Ilyenkor igen nagy a

Joó Ádám · 2015. Júl. 6. (H), 16.13
Ilyenkor igen nagy a kísértés, hogy a külső libbe valaki "belejavít".


Ez azért elég könnyen ellenőrizhető a verziókezelő alapján, és ilyenkor el lehet törni a kezét annak, aki elkövette. Meg ezerféleképp lehet ezt kezelni az integrációs folyamatban, de mondjuk olyan emberekkel szerintem nem érdemes dolgozni, akiknél indokolt az ilyesmi.

Ha sikeres, akkor az éles környezetbe már csak ftp-vel fel tolod a letesztelt kódot.


Ez a legtisztább megoldás szerintem is, függetlenül attól, hogy mi kerül a verziókezelőbe.
6

Miért is kéne eltörni a kezét?

pp · 2015. Júl. 7. (K), 06.07
Ha egy külső libben találsz egy hibát akkor mit teszel?

Én azt szoktam javasolni, hogy javítsák ki a hibát, osszák vissza a megoldást, majd ha a közösségen is átment a hibajavítás, használják az új verziót, addig a sajátot.

Egy adott OpenSource szoftverbe bejuttatni egy hibajavítást, nem mindig egyszerű dolog, nem csak javítani kell a hibát, hanem le is kell kommunikálni, adott esetben erősen pusholni, hogy átmenjen a javaslat. Nem beszélve arról, hogy ott nem csak a mi projektünk lesz a szempont, hanem ezer másik, és a javításnak azoknál a projekteknél is jól kell működni.

Volt már olyan sikersztorim, ahol nálunk 1 órán belül kint volt a fix, és 3 nap múlva már a javított verziót tudtam letölteni, de volt olyan minor fixem is, ami 2 év alatt került be az adott közösségi fejlesztésbe. (és tudok olyan teljesen logikus feature request-ről, ami 8+ év alatt csiszolódott olyanra, hogy bekerülhetett a rendszerbe. :D)

Szóval az, hogy bele kell nyúlni egy külső libbe, az nemkérdés, és az se, hogy ezzel a kérdéssel foglalkozni kell.

Ez azért elég könnyen ellenőrizhető a verziókezelő alapján


Az, hogy visszanézhető a módosítás nagyon kevés, én arra kérdésre keresném inkább a választ, hogy van-e rá mechanizmus ami szól, ha gáz van. Tipikusan amikor a külső lib frissítését teszem fel, rájövök-e könnyedén, hogy meg kell foltoznom azt. Mert ugye az, hogy a tesztrendszerem szól, hogy gond van, kevés, mert nem fogja megmondani nekem, hogy az a gond, hogy a külső libbe bele volt nyúlva, és csak úgy működött az alkalmazás. Persze lehet olyan teszt esetet gyártani, amiből rá lehet jönni könnyedén, mivel csak a módosítás hiánya esetén törik, és a leírásában pedig van utalás arra, hogy mit csináltál.

Visszatérve az eredeti témára, én láttam jól működő fejlesztést így is, úgy is, amiben én hiszek az az, hogy bár a PHP-t nem kell fordítani, mégis megkülönböztetnék build előtti (fejlesztői kód) és build utáni (éles kiadás) állapotokat. Build előtt a külső csomagoknak csak a metainformációit vonnám verziókezelés alá, build után pedig készítenék archivumot az adott build-ekből, és élvezném azt a nagyszerű dolgot, hogy itt a fordítás után is visszaszedhető a forráskód (akár a külső libek kódja is), hogyha esetleg évek múlva kell visszatérni egy projektre.

pp
8

Persze, van, amikor bele kell

Joó Ádám · 2015. Júl. 7. (K), 16.04
Persze, van, amikor bele kell nyúlni egy külső könyvtárba, csak nem mindegy, hogy hogyan, hisz ahogy te is írod, ameddig bekerül a javítás (ha valaha is bekerül, ha egyáltalán beküldjük), addig is tudni kell frissíteni új verzióra.

Én két utat látok ilyen esetekben: vagy érintetlenül hagyjuk a kódot, és az integrációs folyamat részévé tesszük a patchelést, vagy külön projektként kezelve forkoljuk a kódot, és kitaláljuk, hogyan fogjuk követni az upstream változásokat, ebben az esetben viszont módosítást csak annak a projektnek a részeként viszünk be, az alkalmazásunk fejlesztése közben ilyenkor sem nyúlkálunk bele.

Az, hogy visszanézhető a módosítás nagyon kevés, én arra kérdésre keresném inkább a választ, hogy van-e rá mechanizmus ami szól, ha gáz van.


Itt arra gondoltam, hogy ha nem bízunk a csapatunkban (ami rég rossz), akkor az integráció részeként ellenőrizhető, hogy változtak-e a külső könyvtárak, vagy egyszerűen minden alkalommal felülcsaphatóak módosítatlan forrásokkal, függetlenül attól, hogy mit írt át a saját gépén a kolléga.

amiben én hiszek az az, hogy bár a PHP-t nem kell fordítani, mégis megkülönböztetnék build előtti (fejlesztői kód) és build utáni (éles kiadás) állapotokat


Ezzel teljes mértékben egyetértek.

build után pedig készítenék archivumot az adott build-ekből, és élvezném azt a nagyszerű dolgot, hogy itt a fordítás után is visszaszedhető a forráskód (akár a külső libek kódja is), hogyha esetleg évek múlva kell visszatérni egy projektre


Ebben mondjuk nem látom a logikát :)
10

Pont ezért támogatom én a külön tárolást

pp · 2015. Júl. 7. (K), 19.21
Ilyenkor a build folyamatban lesz egy lépés, amikor megfoltozod az adott modult, és ha átírod az új verzióra, és nem lehet foltozni, akkor bukik a build, ráadásul tudod hol keresd a hibát, mert láthatóan a folt lesz az ami bukik.

Szemben azzal, ha egy nagy halom kód között egyszer csak felülcsapja egy update commit a javítást és csak azt látod, hogy nem megy a cucc, de nem tudod, hogy a friss kód miatt nem megy, vagy és itt a kérdés, hogy tudod-e hogy volt folt, szól-e a rendszered ilyenkor, vagy órákat kell túrnod a logot, hogy ezt megtudd.

pp
7

Deployment

vbence · 2015. Júl. 7. (K), 09.43
Egy minimális kürnzeyetben elvégyed a buildet (fuggosegkezeles stb), majd a deploy lépésben rsznc-kel szinkronizálod a szerver fájlrendszerével. A szerveren nem is tanácsos (én nem tanácsolom) composert meg társait futtatni, az nem a "termelés" része.

Az adatbázis migráció (frissités) még tipikusan egy commandline feladat, de ez is megoldható távolról.
9

A szerveren nem is tanácsos

Joó Ádám · 2015. Júl. 7. (K), 16.05
A szerveren nem is tanácsos (én nem tanácsolom) composert meg társait futtatni, az nem a "termelés" része.


Nem is értem, miért olyan divatos ez. A Git repó ugyanez.