Diskuze: Laravel, co vše na server
V předchozím kvízu, Online test znalostí PHP, jsme si ověřili nabyté zkušenosti z kurzu.

Člen

Zobrazeno 6 zpráv z 6.
//= Settings::TRACKING_CODE_B ?> //= Settings::TRACKING_CODE ?>
V předchozím kvízu, Online test znalostí PHP, jsme si ověřili nabyté zkušenosti z kurzu.
Ahoj, to je lehká otázka s těžkou odpovědí. Hodně záleží i na tom, jak při vývoji dodržíš best practice. Dám Ti sem kousek jednoho GitLab CI skriptu pro build funkčního balíčku - bez auto deploymentu a testů. V bloku artifacts je seznam složek a soubor, který pro běh potřebuješ, ale ...
script:
- composer install --prefer-dist --no-ansi --no-interaction --no-progress --no-scripts
- cp .env.gitlabci .env
- php artisan key:generate
- php artisan optimize
- npm install
- npm audit fix
- npm run prod
artifacts:
expire_in: 1 month
paths:
- app/
- bootstrap/
- config/
- database/
- node_modules/
- public/
- resources/
- routes/
- storage/
- vendor/
- artisan
Složka node_modules a příkazy npm odpovídají tomu, že děláme frontend ve Vue.js. Bez toho nebo jiných npm závislostí tam být nemusí.
Nikde mimo soubory ve složce config nesmíš používat načítání konfigurace metodou env(), jinak bys musel přidat i soubor .env. Stejně tak ho musíš přidat, pokud nepoužiješ příkaz artisan config:cache (je i součástí artisan optimize).
Když je konflikt prostředí s composer.lock a composer.json, nemusí se správně nastavit autoload a pak tam musel být i composer.json. Ani to není optimální stav, ale může se stát.
Kdybys dělal řeba testovací build a automatizované PHPUnit testy, budeš potřebovat taky složku tests, soubor phpunit.xml a případně i .env.testing, kde si uděláš nastavení pro testování, jako jsou testovací databáze, sandbox protředí atd.
Takže na tvůj dotaz není úplně snadné odpovědět
Takže zhruba odpověď kterou jsem tak nějak očekával, každopádně díky.
Jen bych rád doplnil, že i .env
se používá normálně na
produkci. V konfiguračních souborech pouze používáš jeho hodnoty, tudíž
nedojde ke konfliktu na Gitu a také neukládáš citlivá data na Git.
S neumítěním .env na Git souhasím, ale jinak bych si troufal oponovat. Hodně ovšem záleží na tom, jak máš postavený deployment na produkci. Nicméně z dokumentace Laravelu.
You should typically run the php artisan config:cache command as part of your production deployment routine.
A k tomu další poznámka.
If you execute the config:cache command during your deployment process, you should be sure that you are only calling the env function from within your configuration files. Once the configuration has been cached, the .env file will not be loaded and all calls to the env function will return null.
Pokud tedy dodržíš, že při deploymentu na produkci uděláš artisan config:cache, je Ti umístění .env na produkci k ničemu, protože se již nenačítá. Naopak pro lokální vývoj je jako best practice popsáno nepoužívat config:cache a pracovat klasicky s .env.
Teď už to chápu. Ty chceš vytvořit mezipaměť konfigurace a tu umístit na produkci. Což samozřejmě lze, nejsem si však jist, jestli se jedná o best-practices. Ne vždy se musí web nahrávat nebo aktualizovat jenom z Gitu, ale lze také použít externí služby jako je Envoyer přímo od samotných vývojářů frameworku. A ten pouze pracuje se soubory z Gitu, nikoliv však už s jeho Gitlab CI/CD, popř. Github Workflows, jelikož má svoje skripty, které lze upravovat.
Zobrazeno 6 zpráv z 6.