Rozwi膮zywanie problem贸w
Konfiguracja projektu polega r贸wnie偶 na posiadaniu odpowiednich narz臋dzi do debugowania. Na szcz臋艣cie wiele przydatnych narz臋dzi jest ju偶 zawartych w pakiecie webapp
.
Odkrywanie narz臋dzi Symfony do debugowania
Na pocz膮tek, Symfony Profiler, kt贸ry oszcz臋dza czas podczas szukania 藕r贸d艂a problemu.
Je艣li spojrzysz na stron臋 g艂贸wn膮, u do艂u ekranu powiniene艣/a艣 zobaczy膰 pasek narz臋dzi:
Pierwsz膮 rzecz膮, jak膮 mo偶esz zauwa偶y膰, jest czerwone 404. Pami臋taj, 偶e ta strona jest elementem tymczasowym, poniewa偶 nie zdefiniowali艣my jeszcze strony g艂贸wnej. Nawet je艣li strona domy艣lna, kt贸ra Ci臋 wita, jest ca艂kiem 艂adna, to jest to tylko strona b艂臋du. Wi臋c prawid艂owy kod statusu HTTP to 404, a nie 200. Dzi臋ki paskowi narz臋dzi do debugowania widzisz to od razu.
Je艣li klikniesz na ma艂y wykrzyknik, otrzymasz pe艂n膮 informacj臋 opisuj膮c膮 wyj膮tek jako cz臋艣膰 log贸w w profilerze Symfony. Je艣li chcesz zobaczy膰 艣lad stosu (ang. stack trace), kliknij na odno艣nik "Exception" w lewym menu.
W przypadku pojawienia si臋 problemu z kodem zobaczysz stron臋 z wyj膮tkiem, tak膮 jak poni偶sza, kt贸ra daje Ci wszystko, czego potrzebujesz, aby zrozumie膰 problem i 藕r贸d艂o jego pochodzenia:
Po艣wi臋膰 troch臋 czasu na poznanie informacji zawartych w profilerze Symfony klikaj膮c na niego.
Logi s膮 r贸wnie偶 bardzo przydatne podczas debugowania. Symfony posiada wygodne polecenie 艣ledzenia wszystkich log贸w (z serwera WWW, PHP i Twojej aplikacji):
1
$ symfony server:log
Przeprowad藕my ma艂y eksperyment. Otw贸rz public/index.php
i zepsuj co艣 w kodzie PHP (np. dodaj foobar w 艣rodku kodu). Od艣wie偶 stron臋 w przegl膮darce i obserwuj strumie艅 dziennika:
1 2
Dec 21 10:04:59 |DEBUG| PHP PHP Parse error: syntax error, unexpected 'use' (T_USE) in public/index.php on line 5 path="/usr/bin/php7.42" php="7.42.0"
Dec 21 10:04:59 |ERROR| SERVER GET (500) / ip="127.0.0.1"
Wyj艣cie jest pi臋knie pokolorowane, aby zwr贸ci膰 uwag臋 na b艂臋dy.
Zrozumienie 艣rodowisk Symfony
Poniewa偶 Symfony Profiler jest przydatny tylko podczas developmentu, chcemy unikn膮膰 instalowania go w 艣rodowisku produkcyjnym. Domy艣lnie Symfony instaluje go tylko dla 艣rodowisk dev
i test
.
Symfony w pe艂ni wsp贸艂gra z ide膮 艣rodowisk w aplikacji. Framework ten wspiera domy艣lnie trzy r贸偶ne 艣rodowiska: dev
, prod
i test
, ale mo偶esz doda膰 kolejne. Wszystkie 艣rodowiska wsp贸艂dziel膮 ten sam kod, ale wykorzystuj膮 r贸偶ne konfiguracje.
Na przyk艂ad wszystkie narz臋dzia do debugowania s膮 w艂膮czone w 艣rodowisku dev
. W 艣rodowisku prod
aplikacja jest zoptymalizowana pod k膮tem wydajno艣ci.
Prze艂膮czanie si臋 z jednego 艣rodowiska do drugiego mo偶na wykona膰 poprzez zmian臋 zmiennej 艣rodowiskowej APP_ENV
.
Po wdro偶eniu na platform臋 Platform.sh, 艣rodowisko (przechowywane w APP_ENV
) jest automatycznie prze艂膮czane na prod
.
Zarz膮dzanie konfiguracjami 艣rodowisk
Zmienna APP_ENV
mo偶e by膰 ustawiona za pomoc膮 "prawdziwych" zmiennych 艣rodowiskowych w terminalu:
1
$ export APP_ENV=dev
Korzystanie z rzeczywistych zmiennych 艣rodowiskowych jest rekomendowanym sposobem ustawiania warto艣ci takich jak APP_ENV
na serwerach produkcyjnych. Ale na maszynach deweloperskich konieczno艣膰 zdefiniowania wielu zmiennych 艣rodowiskowych mo偶e by膰 uci膮偶liwa. Zamiast tego definiuj je w pliku .env
.
Gotowy plik .env
zosta艂 wygenerowany automatycznie w momencie tworzenia projektu:
Tip
Ka偶dy pakiet mo偶e doda膰 wi臋cej zmiennych 艣rodowiskowych do tego pliku dzi臋ki przepisowi (ang. recipe) u偶ywanemu przez Symfony Flex.
Plik .env
, kt贸ry zawiera warto艣ci domy艣lne 艣rodowiska produkcyjnego, jest przechowywany w repozytorium. Mo偶esz nadpisa膰 te warto艣ci tworz膮c plik .env.local
. Plik ten nie powinien by膰 zatwierdzany (ang. commit) i dlatego .gitignore
domy艣lnie go ignoruje.
Nigdy nie przechowuj poufnych lub wra偶liwych danych w tych plikach. W kolejnym kroku zobaczymy, jak zarz膮dza膰 poufnymi danymi.
Skonfiguruj swoje IDE
W 艣rodowisku deweloperskim, kiedy wyj膮tek zostaje rzucony, Symfony wy艣wietla stron臋 z komunikatem o wyj膮tku i jego stosem. Podczas wy艣wietlania 艣cie偶ki do pliku dodaje odno艣nik, kt贸ry otwiera plik we w艂a艣ciwej linii w Twoim ulubionym IDE, je艣li je odpowiednio skonfigurujesz. Symfony obs艂uguje wiele IDE tu偶 po instalacji - w tym projekcie u偶ywam Visual Studio Code:
1 2 3 4 5 6 7
--- a/php.ini
+++ b/php.ini
@@ -6,3 +6,4 @@ max_execution_time=30
session.use_strict_mode=On
realpath_cache_ttl=3600
zend.detect_unicode=Off
+xdebug.file_link_format=vscode://file/%f:%l
Odno艣niki do plik贸w nie s膮 ograniczone tylko do wyj膮tk贸w. Dla przyk艂adu, kontroler w pasku narz臋dzi do debugowania staje si臋 klikalny po odpowiednim skonfigurowaniu IDE.
Debugowanie w 艣rodowisku produkcyjnym
Debugowanie serwer贸w produkcyjnych jest zawsze trudniejsze. Nie masz dost臋pu na przyk艂ad do profilera Symfony. Dzienniki log贸w s膮 mniej szczeg贸艂owe, ale 艣ledzenie ostatnich zapis贸w jest mo偶liwe:
1
$ symfony cloud:logs --tail
Mo偶esz nawet po艂膮czy膰 si臋 przez SSH z kontenerem webowym:
1
$ symfony cloud:ssh
Nie martw si臋, niczego 艂atwo nie zepsujesz. Wi臋ksza cz臋艣膰 systemu plik贸w jest tylko do odczytu. Nie b臋dziesz w stanie wykona膰 pilnej poprawki w 艣rodowisku produkcyjnym, ale nie przejmuj si臋, w kolejnych rozdzia艂ach tej ksi膮偶ki nauczysz si臋 o wiele lepszego podej艣cia.