Laravel: Automatyczny deployment

5.8.x

0:00W tej lekcji pokażę ci jak z użyciem deployer, a jest to takie narzędzie do

0:04wdrażania aplikacji PHP'owych, jak możemy wdrożyć naszą aplikację

0:09laravel. Ja korzystam na codzień z deployer'a, naprawdę świetnie to działa. Jeżeli

0:13sobie to odpowiednio skonfigurujemy. Jest to darmowe i oferuje nam Zero Downtime Deployment. Będzie

0:18to właśnie takie wdrażanie, które nie przerwie działania naszej strony, więc nawet jeżeli ktoś

0:22będzie w trakcie zakupów na naszej stronie, możemy podmienić całą stronę i

0:26nie zostanie taki proces zakupowy przerwany, więc jest bardzo ważne i

0:30teraz to narzędzie można sobie zainstalować jeżeli masz Maca albo linux'a. Na Windowsie

0:34niestety nie będzie działać, ale możemy go zainstalować również wewnątrz wirtualnej

0:39maszyny, którą mamy na Linux'ie i wtedy będzie porządku, aczkolwiek, no,

0:43to jest może bo trochę bardziej kłopotliwe, żeby z tej wirtualnej maszyny robić deployment'y, bo

0:47musisz ją za każdym razem uruchomić, w każdym razie zainstalujemy sobie deployer'a w

0:51takim razie w wirtualnej maszynie. Jeżeli masz Linux'a lub Maca, dokładnie te

0:55same komendy możesz wykonać u siebie w terminalu i będzie działać. Natomiast

1:00ja chcę je wykonać wewnątrz maszyny wirtualnej, więc zróbmy

1:04sobie to po kolei, przejdziemy tutaj, jestem tutaj zalogowany. Pobierzemy deployer.phar,

1:10następnie po prostu przeniesiemy go do katalogu user

1:14local bin i nazwiemy jako dep i od tej pory on będzie dostępny pod

1:20komendą dep po prostu, więc możemy z dep korzystać i teraz ostatnia

1:24rzecz to będzie jeszcze nadanie mu uprawnień, żeby to był plik wykonywalny. No

1:28i wystarczy, teraz za pomocą komendy dep zostanie utworzony plik deploy php,

1:33ale ja już ten plik mam i on jest prekonfigurowany przeze

1:37mnie wcześniej, więc po prostu pokażę ci jak on działa i teraz ważne, że deployer ma

1:41różne przepisy, czyli list recipes i mamy

1:45tutaj jedną z nich, jest to przepis na laravel. Możesz

1:50zauważyć że tutaj są za pomocą takich różnych funkcji, to są funkcje właśnie tego deployer'a, konfigurowane

1:56zadania laravel'owe, czyli na przykład task nazywa się artisan

2:00app i tutaj deployer próbuje w deploy path, czyli tam gdzie jest

2:04nasza aplikacja, uruchomić artisan, więc jak to

2:08dokładnie wygląda, że tutaj jeździ się dobrze przyjrzysz, to są komendy artisan'owe, głównie

2:13używane, a także linuksowe komendy, które robi deployer po to, żeby

2:18na przykład w odpowiedni sposób nadać uprawnienia do plików i tak dalej. Tutaj

2:22domyślnie writeable dirs to są te katalogi, więc deployer postara nadać

2:26takie uprawnienia, żebyśmy nie mieli żadnych błędów na stronie, że na przykład

2:30nasza aplikacja nie ma uprawnień do zapisywania w jakimś pliku. Jeżeli

2:34chodzi o shared files to możesz zobaczyć, że tutaj jest to plik env, który

2:38w poprzedniej lekcji zrobiliśmy, również storage, który tam otworzyliśmy. One

2:43będą współdzielone pomiędzy poszczególnymi wdrożeniami, więc to

2:47jest taki przepis, który możemy sobie zaimportować, więc ja tutaj utworzyłem plik deploy php,

2:53troszeczkę jest przeze mnie on zmodyfikowany, dlatego że ja sobie dodałem jeszcze

2:57takie sprawdzenie zaraz jak będziemy wykonywać deploy to zobaczysz

3:01po co ono jest. Natomiast tutaj mamy właśnie ten przepis laravel. Ja sobie zawsze

3:05go tutaj linkuje, jeżeli potrzebuje sprawdzić jak konkretne zadania wyglądają. Teraz

3:10przejdziemy szybko przez konfigurację, możesz zobaczyć, że tutaj ustawiamy

3:14użytkownika http na www-data. Jeżeli korzystasz z nginx'a domyślnie

3:18tak będzie. Teraz repozytorium git'a, bo będziemy chcieli robić push repozytorium

3:22git'a i ono będzie na naszym serwerze, a następnie deployer będzie z niego zaciągał

3:27świeży kod, więc tutaj podajemy ścieżkę na serwerze gdzie to repozytorium się będzie

3:31znajdować i możesz go umieścić na przykład w katalogu domowym użytkownika, ale

3:35ja robię to zawsze w opt git i tutaj jest nasze repozytorium, więc teraz

3:39sobie do repozytorium utworzymy. Ja jestem już tutaj na serwerze zalogowany,

3:44przejdę do opt i chciałbym tutaj utworzyć katalog git, musimy tu zrobić

3:48sudo, bo nie mamy dostępu do katalogu opt, więc

3:52sudo i następnie mk dir git, okej. On się

3:56utworzył i teraz będę chciał temu katalogowi nadać uprawnienia dla użytkownika

4:01laravel, bo to on będzie wykonywał później push kodu, zatem wpiszemy

4:05sudo chown minus r laravel,

4:09to jest nazwa nazwa użytkownika, nazwa grupy i następnie nazwa katalogu,

4:13czyli git. Teraz przejdę do git i już jako użytkownik laravel mogę tutaj sobie tworzyć

4:18własne katalogi czy repozytoria. Na serwerze musisz mieć zainstalowanego git'a i wpiszemy

4:22git init i następnie larablogger git,

4:26natomiast chciałbym jeszcze zrobić tutaj bare, że to jest takie puste

4:31repozytorium. Zauważ, że ono się tutaj pojawiło i jeżeli podejrzymy

4:35ścieżkę to jest dokładnie ta ścieżka, którą podaliśmy tutaj, więc będzie

4:39mógł deployer sobie stamtąd zaciągnąć zmiany. Teraz będziemy musieli skonfigurować

4:44remote tego repozytorium u nas lokalnie, więc przejdziemy do tej wirtualnej

4:48maszyny na które już mamy zainstalowane git. Jeżeli będziesz to robił na Macu to możesz

4:52to zrobić nie wewnątrz wirtualnej maszyny, ale u siebie i w miejscu gdzie mamy to repozytorium,

4:56jeżeli byśmy wpisali git status, to jak widzisz, coś nam się tutaj

5:00pojawia, dlatego że git jest zainstalowany, a więc chcemy dodać znany, taki

5:05adres remote, więc napiszemy git remote add

5:09i teraz jest bardzo ważne, wpiszemy ssh, taki będzie protokół. Następnie

5:14użytkownika, użytkownik jest to laravel. Tutaj musimy podać host,

5:18czyli w moim przypadku jest to larablogger.pl port, domyślnie

5:23jest to port 22 dla ssh, ale ja żeby zabezpieczyć serwer zawsze

5:27zmieniam ten port na inny i w moim przypadku ten port jest to 2241, dlatego

5:31tutaj podam i następnie ścieżka docelowa już do repozytorium, czyli

5:35będzie to opt git i nazwaliśmy je larablogger git.

5:40Okej, dodajmy sobie coś takiego, jeszcze

5:45oczywiście nazwę musimy podać, czyli git remote add i nazwa nazwa to będzie production,

5:49w ten sposób, jeżeli wpiszemy git

5:53remote minus v, to widzimy, że tutaj mamy nadane różne

5:58origin'y. Jeden z nich to jest ten, który ja mam skonfigurowany do pracy nad kursem,

6:02a drugi to będzie teraz dodany właśnie production, czyli pierwszy to jest nazwa origin,

6:06drugi nazwa production i teraz jak normalnie wykonujesz git push to tutaj będziesz

6:10mógł wpisać git push production i wtedy wyślemy to na ten serwer. Natomiast ważne jest to, żeby

6:15mieć skonfigurowane wcześniej klucze ssh, czyli musiałem na serwerze dodać

6:19klucz ssh dla użytkownika laravel właśnie tej wirtualnej maszyny, w

6:23której teraz jestem, po to żeby można było taki kod wysłać i to jest to o czym wspomniałem

6:27wcześniej, to są troszeczkę bardziej zaawansowane koncepcję, z którymi jeżeli

6:31jesteś zaznajomiony, to sobie poradzisz z tą konfiguracją, więc wtedy taki

6:36kod będziemy mogli już wysyłać. No i spróbujemy czy to się uda zrobić, okej.

6:40Teraz wpiszemy git push production i na

6:45nasz serwer powinny zostać wysłane wszystkie pliki, całe repozytorium. Jak widzisz,

6:50tak też się stało. Teraz jeżeli byśmy tutaj przeszli, mamy ten plik, jeżeli sprawdzimy

6:54ile on zajmuje, to okaże się, że jest około megabajta, czyli

6:58coś tutaj już pojawiło, nic tutaj nie będziemy zmieniać, tutaj po prostu będziemy wykonywać

7:02takie push'e produkcyjne. Teraz natomiast przejdźmy sobie do var www, następnie do larablogger i

7:08tutaj do html, jak widzisz na razie mamy tylko shared

7:12skonfigurowany z plikiem env, natomiast będziemy chcieli wykonać

7:16sobie właśnie deployment i to o czym wspomniałem wcześniej, że ja tutaj skonfigurowałem

7:20parę rzeczy, bo nie chce w tym pliku, który jest dodawany do repozytorium zapisywać

7:25nazwy użytkownika czy portu na którym mój serwer operuje, dlatego zrobiłem

7:29to w ten sposób, że przy wykonywaniu deployer'a będziemy mogli podać użytkownika

7:33jako zmienną właśnie taką środowiskową. Myśmy zmienną user

7:38oraz port i one tutaj będą przechwycone i będą podstawione w odpowiednie

7:42miejsce, dlatego że tutaj użytkownika, który po ssh się loguje oraz

7:46port trzeba podać. Tutaj jest oczywiście nazwa hosta. Zatem teraz

7:50prosta rzecz, mamy zainstalowane już deployer, wpiszemy

7:55dep deploy i tyle

7:59w zasadzie wystarczy. Powiem ci jeszcze, że tutaj można różne stage ustawiać, w razie czego

8:03o tym doczytaj. Możesz mieć stage testowy i produkcyjny, możesz potem wpisać dep deploy na przykład test

8:08do serwera testowego albo do tego samego serwera tylko do innych katalogów albo dep deploy

8:13production samo dep deploy wykona nam to co tutaj mamy ustawione, ale to

8:17nam nie zadziała, zobacz. Dlatego, że nie podaliśmy użytkownika i portu. To jest właśnie

8:21to moje sprawdzenie, które ja sobie dodałem jakiś czas temu i żeby je podać, wpisujemy

8:25tutaj user równa się nazwa użytkownika. W moim przypadku jest to laravel

8:30i następnie port, w moim przypadku jest to tak jak mówiłem 2241

8:35i dopiero teraz dep deploy i te zmiany zostaną przekazane jakby

8:39do tego pliku i wszystko powinno się poprawnie wykonać. Nie mniej jednak

8:43sprawdźmy. Czekamy

8:47sobie, to może chwilę potrwać, ale fajne jest to, że oczywiście wszystko jest zautomatyzowane. Jeżeli

8:52będą jakieś błędy, to nasza aplikacja po prostu się nie podmieni, ale o tym jeszcze za sekundę,

8:56zadanie, które widzisz deploy vendors tak naprawdę na serwerze uruchamia composer'a

9:00i ten composer instaluje wszystkie zależności, więc na serwerze oprócz tego, że trzeba

9:04mieć zainstalowany php, php fpm do wykonywania właśnie

9:09tych wszystkich procesów, nginx'a MySQL, no to jeszcze trzeba mieć composer'a. Na

9:14koniec tej lekcji jeszcze powiem ci jak możesz zrobić to prościej. Jeżeli

9:18nie wiesz jak skonfigurować serwer i można to za pomocą pewnego narzędzia, ona

9:22jest płatne, dlatego pokażę go dopiero na końcu, nie będę pokazywał

9:26jak z niego korzystać, ale zobaczysz, że również taka możliwość jest. Jeżeli

9:30nie masz wiedzy temat zarządzania serwerami. Teraz po kolei wykonały

9:35się wszystkie zadania. Ja jeszcze ci pokażę może w pliku, że mam kilka

9:39zadań dodatkowo skonfigurowanych, czyli mówię po zadaniu, która nazywa się artisan config cache. Teraz skąd

9:45ja wiem kiedy to zadanie się wykonuje? Otóż tutaj jest na samym dole lista

9:49kiedy one się wykonują i widzę config cache to

9:53gdzieś tutaj się znajdzie jest dokładnie tutaj. Że ono

9:57jest tym właśnie miejscu, więc ja po nim chcę sobie wykonać zadanie artisan q restart. My w tym kursie

10:02nie korzystaliśmy z kolejek, ale zostawiam tutaj na przyszłość, dlatego że może

10:06to być bardzo przydatne. Dla mnie zawsze jest przydatne. Takie kolejki muszą być zrestartowane, żeby

10:10załapały nowy kod. Następnie przed zadaniem symlink chcę wykonać

10:14jeszcze migrate, którego domyślnie tutaj nie ma. Czyli fajne jest to, że jeżeli tutaj mamy jakieś

10:19migracje i dodajemy na przykład jakąś nową tabelę w bazie danych, to kiedy zrobimy git

10:23push production i wykonamy deployera, to również migrate się wykona i wszystko będzie

10:27działać poprawnie. Jeżeli oczywiście nie popełniliśmy

10:31jakiegoś błędu i teraz po zadaniu deploy failed, jeżeli

10:35się z jakiegoś powodu nie uda to chcemy odblokować deploy unlock, to sprawi że będzie

10:39można po raz kolejny skorzystać z zadania deploy, okej.

10:43W każdym razie być może to się wszystko udało. Jeżeli teraz sobie zobaczymy co w tym katalogu

10:47jest, to pojawił się katalog current, do którego pamiętasz być może linkowaliśmy

10:51z nginx'a, czyli tutaj wskazuje serwer i teraz jak przyjdziemy do katalogu

10:55current to się okaże, że jest tutaj cała nasza aplikacja, ale ten katalog current wrócę

11:00do góry, jest symlinkowany, czyli on jest przekierowany do releases

11:041 i to releases jest właśnie tutaj jest. Jeżeli,

11:09jeśli byśmy tam przeszli jest tutaj jeden. Po pierwsze sprawdźmy czy nasza strona zaczęła

11:13działać. Jak widzisz tak, nie mamy żadnych wpisów, bo w bazie danych oczywiście

11:18nic nie ma, ale strona już działa i teraz jeżeli byśmy tutaj przeszli

11:22sobie to current to normalnie możemy wykonać php

11:26artisan tinker i na przykład w tym tinkerze dodać sobie coś

11:30do bazy danych albo możemy wykonać php artisan db:seed w

11:34ten sposób i powinno nam się wszystko do bazy danych dodać

11:38zobaczmy. Tutaj oczywiście ustawiliśmy w pliku env, że jesteśmy na

11:42produkcji, więc on pyta czy pewno chcemy pewne rzeczy robić, bo jesteśmy w produkcji. Mówię

11:47tak i pojawił nam się jakiś błąd, okej, wiemy o co chodzi. Ten

11:52błąd się pojawił dlatego, że composer instaluje tutaj zależności tylko te, które

11:56są potrzebne do produkcji, a pomija te development'ckie a Faker jest jedną

12:00z development'ckich, dlatego tutaj akurat nam to seed'owanie bazy danych w ten sposób

12:04z Faker'em nie zadziała. Moglibyśmy mieć te seeder'y napisane w inny sposób, na przykład z

12:08pliku wczytywać jakieś dane i tak dalej. Nie mniej jednak nie jest to takie istotne, spróbujmy

12:12sobie zarejestrować użytkownika. Wiemy, że pierwszy użytkownik zarejestrowany na naszej

12:16stronie to będzie admin, dlatego ja się tutaj zarejestruje, wciskam

12:21enter, i mail się jeszcze będzie wysyłał przez mailtrap'a

12:25i mamy 500 Server Error, czyli coś poszło nie tak. Jak

12:29widzisz już nie mamy komunikatu o błędzie, ale wygląda to w taki sposób, możemy tą templatkę

12:33dostosować. Zatem jeżeli pojawi się błąd, to oczywiście warto będzie zerknąć

12:38jaki to jest błąd. Przejdziemy sobie do storage, który jest też tutaj podlinkowany,

12:42logs i tutaj zobaczymy te błędy, bo tak jak ci pokazywałem w lekcji o

12:46błędach, one się będą pojawiać. Mogę wyświetlić taki błąd i zobaczymy na czym on

12:50polega. To był błąd wcześniejszy z klasą faker, a

12:54tutaj jest błąd o wysyłaniu wiadomości email. Okej, czyli jest ten sam

12:58błąd, który mieliśmy wcześniej, jak widzisz tylko dlatego, że za dużo chcemy na sekundę wysłać

13:02tych emaili, a nie pozwala na to mailtrap. Natomiast tutaj

13:06domyślnie zmienilibyśmy to oczywiście na prawdziwe dane smtp,

13:12ale wygląda na to, że użytkownik się zarejestrował tylko po prostu nie

13:16otrzymamy maila. Okej, zatem wróćmy do aplikacji. Jeżeli teraz

13:20tutaj przejdę to powinniśmy już być zarejestrowani. Tak też stało, jestem

13:24od razu zalogowany, a więc ten błąd dla nas akurat tutaj nie jest kluczowy i istotny. Jestem

13:29adminem, więc mogę utworzyć jakiś nowy wpis, spróbujmy. Może

13:33nazwiemy go w ten sposób, wybierzemy że jest to type photo. Data będzie domyślna,

13:38tagi możemy jakieś sobie dodać, na przykład photo image. Chcę,

13:42żeby on był opublikowany, nie musi być wpisem premium i dodam mu jakiś obrazek,

13:49okej. Sprawdźmy add post. No i się udało ten wpis się

13:53pojawił. Jedna ważna uwaga. Jeżeli na przykład będziesz wysyłał obrazki

13:57czy pliki na serwer i będziesz miał błędy że za dużo takie pik zajmuje to czasami

14:02są to błędy konfiguracji samego php, ale często również wynika to z konfiguracji

14:06nginx'a, który nie przyjmuje zbyt dużych plików. Tutaj ten plik nie był duży, więc

14:10się wszystko udało i wierz mi lub nie, ale wszystko co tutaj robimy jest wykonywane na

14:14prawdziwym serwerze. Nie jest to u mnie lokalnie. Jest to prawdziwy serwer z prawdziwą

14:18domeną. No i jak widzisz wszystko nam tutaj ładnie działa, więc na koniec pokażę

14:23ci jeszcze w jaki sposób możemy coś zmienić i jeżeli coś zmienisz jak

14:27możemy zrobić deployment. Zatem wrócimy sobie do kodu, tutaj

14:32jeszcze wykomentowałem jedno z zadań, dlatego że domyślnie deployer

14:36wykonuje zadanie artisan cache clear i to jest w porządku, żeby wyczyścić

14:41pamięć podręczną, ale nie zawsze. Ja w swoich aplikacjach wykorzystuje często pamięć

14:45podręczną bazy danych redis do przechowywania kluczowych danych

14:49i dlatego nie chcę żeby za każdym deployment'em te dane były czyszczone, a więc wtedy dodaje

14:53sobie takie zadanie, czyli nadpisuje zadanie które w tym przepisie

14:58znalazłem i dodaje sobie po prostu skipping, czyli chcę żeby to zadanie było pomijane.

15:02Niemniej jednak tu może zostać to w ten sposób. Okej zatem co

15:06możemy zmienić naszej aplikacji, żeby te zmiany na stronie zobaczyć, może

15:10tutaj w pliku master sobie coś podmienimy, na przykład sam

15:14tytuł. Tyle wystarczy, natomiast zapewniam cię jeżeli dodasz jakieś

15:18migracje, zrobisz cokolwiek, co zrobiliśmy wcześniej, również będzie w porządku. Teraz przejdziemy

15:22tutaj gdzie mamy repozytorium git'a i musimy te zmiany dodać, więc

15:27napiszemy git add git commit. Zmiany trzeba

15:31zacommit'ować. Napiszemy na przykład change app

15:36version. To są jakieś zmiany, które wykonałeś, okej udało się

15:40i teraz zrobimy git push production, czyli dwa kroki musisz

15:45wykonać, żeby wdrożyć swoją aplikacje. Pierwszy z nich to jest git push production i

15:49to wyślę kod na nasz serwer, a druga rzecz jest o

15:53wpisanie tak jak mieliśmy wcześniej user laravel

15:59podanie portu i napisanie dep deploy. Możemy tutaj również podać taką flagę

16:03verbose i będziemy widzieć co się dokładnie dzieje. Jeżeli podamy dwa razy v,

16:07to będziemy jeszcze mieć dokładniejsze info, a 3 razy to będzie już super dokładna

16:12informacja jakie dokładnie komendy wykonuje deployer, więc możemy testowo sobie to

16:16zrobić. Widzisz dokładnie każdą komendę, którą za nas wykonuje deployer,

16:21nie musimy już przez FTP w jakiś sposób wgrywać naszej aplikacji, instalować zależności

16:25composer'a i tak dalej. Wszystko dzieje się automatycznie i zauważ jak bardzo szybko ten

16:29deployment się wykonał. W międzyczasie oczywiście każdy mógł korzystać z

16:33naszej strony, bo dopiero kiedy się uda ten deployment zrobić kiedy wszystko

16:38się zainstaluje to jest zrobione symlink i widać to tutaj czyli release,

16:42który mieliśmy. Teraz jeśli tam przejdziemy w to

16:48miejsce zrobię ls releases, to się okaże, że tutaj jest 1

16:52i 2, dlatego, że możemy wykonywać również dep, zamiast deploy to

16:56możemy wykonać rollback I wtedy cofniemy się do poprzedniego release'u,

17:01czyli wydania. Teraz ten drugi został podlinkowany i jeżeli sobie przejdziemy

17:05czy odświeżymy tutaj listę wpisując ll, to widzimy,

17:09że katalog current, na który kieruje nginx, teraz kieruje już do releases 2. Jeżeli

17:14przejdziemy na stronę i odświeżę najadę na tytuł, zauważ,

17:18że w tym tytule pojawia się larablogger v2, czyli nasza strona została zaktualizowana

17:23za pomocą deployer'a i jeżeli ktoś by klikał po tej stronie tutaj

17:27coś robił, to nawet by nie zauważył momentu w to by się stało. Na

17:31koniec jeszcze jedna ważna uwaga jeżeli chodzi o zasoby frontendowe. Powinniśmy

17:35je tutaj budować, jeżeli zobaczymy plik package json,

17:39to w tym pliku my uruchamialiśmy npm run watch, ale

17:43jest tutaj również coś takiego jak run pro i to nam wykona produkcyjnego build'a,

17:48więc warto również to robić i dopiero później wysyłać to wszystko na serwer. Możesz

17:52skonfigurować sobie to tak, że za każdym razem jak będziesz wykonywał commit, to wykona

17:57się również npm run prod. Możesz to zrobić z użyciem takiej paczki,

18:01która nazywa się husky. Niemniej jednak, możemy to również zrobić ręcznie, bo już

18:05tego husky nie będę tutaj konfigurował. Będąc tutaj wpiszemy npm run

18:10prod. Wszystkie nasze zasoby czyli CSS,

18:14JavaScript, one zostaną zoptymalizowane. Oczywiście plik, który tutaj mieliśmy

18:18wcześniej mix-manifest również zaktualizuje te hash'e które są później

18:22podstawiane tam gdzie linkujemy do tych zasobów. No i za moment

18:26jeszcze raz wykonamy sobie deployment i te zasoby tam już będą wczytywane. Natomiast

18:30zanim to się tutaj wykonuje, to pokażę ci że jeżeli podejrzymy źródło strony i zobaczymy

18:35na przykład CSS to jak widzisz jest on nie zminifikowany. Za moment

18:39jednak to ulegnie zmianie, ale zmieni się również tutaj jego hash, okej

18:44to się udało i teraz jeszcze raz zrobimy sobie git add, dodamy wszystko git

18:48commit, message to będzie add production assets. To

18:54oczywiście warto robić przy każdym commit'cie, który zamierzasz wysłać na serwer, okej i

18:59teraz znowu deployment, czyli git push production, to się wysyła dokładnie

19:04na serwer i następnie raz jeszcze user i deploy.

19:09Może tym razem już bez tych flag verbose. Poczekamy chwilkę i na

19:13naszej stronie powinno być już wczytywane zoptymalizowane zasoby, ale jak wspomniałem jeżeli skorzystał byś

19:17z husky, to jak będziesz robił commit, to automatycznie również te zasoby będą

19:21optymalizowane. Teraz jeszcze raz przyjdziemy na naszą stronę, odświeżam i wszystkie

19:26zasoby powinny być wczytane od nowa. Jeżeli zobaczymy main, jest to tym razem

19:30już plik zminifikowany i podobnie będzie również z plikami JavaScript'owymi. Jak

19:35zatem widzisz deployment jeżeli wszystko skonfigurujemy jest dziecinnie prosty. Pracuje lokalnie

19:39nad swoją aplikacją. Dodaje ją do repozytorium git'a. Wykonuje git push production

19:44i następnie dep deploy i aplikacja jest podmieniana w sposób

19:48Zero Downtime, czyli cały czas można korzystać ze strony internetowej i

19:52zostanie ona podmieniona i zsimlinkowana tak naprawdę w

19:56ułamku sekundy, ale jest to tak zwane atomic symlink, więc nie ma możliwości,

20:00żeby coś tutaj się popsuło. Na koniec pokażę ci jeszcze jedno rozwiązanie, jeżeli

20:04nie potrafisz skonfigurować serwera VPS lub nie chcesz tego uczyć, mówię

20:08tutaj o instalacji php nginx'a i wszystkich tych rzeczy. Nie jest bardzo skomplikowane,

20:13aczkolwiek trzeba trochę nad tym popracować, to pokażę ci jak możesz to zrobić

20:17automatycznie. Jest takie narzędzie które nazywa się laravel forge i ono

20:21jest płatne, aczkolwiek pozwoli ci bardzo, bardzo prosty również

20:25z użyciem tylko git'a wdrażać aplikacje. Skonfiguruję za ciebie

20:29serwer w popularnych serwisach lub własny custom'owy VPS, który tutaj podasz

20:34i następnie pozwoli ci git'em wysyłać tylko zmiany, a wszystko

20:38będzie automatycznie wdrażane, czyli będzie jeszcze jeden krok mniej niż jest u nas.

20:42U są dwa kroki git push i następnie deb deploy. Nie jest to żaden problem, tutaj

20:46będzie jeszcze jeden krok mniej, więc w razie czego możesz również tego narzędzia skorzystać.