Laravel egy átlagos tárhelyen
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.
■ 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.
Nagyon egyszerű, tárhelyet
Én egy ideje a külső
Tehát én az első alternatívát javaslom.
Artisan facade
még a vendor mappát is -
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.
Ilyenkor igen nagy a
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.
Ez a legtisztább megoldás szerintem is, függetlenül attól, hogy mi kerül a verziókezelőbe.
Miért is kéne eltörni a kezét?
É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.
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
Persze, van, amikor bele kell
É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.
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.
Ezzel teljes mértékben egyetértek.
Ebben mondjuk nem látom a logikát :)
Pont ezért támogatom én a külön tárolást
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
Deployment
Az adatbázis migráció (frissités) még tipikusan egy commandline feladat, de ez is megoldható távolról.
A szerveren nem is tanácsos
Nem is értem, miért olyan divatos ez. A Git repó ugyanez.