Prosta metoda deployowania aplikacji Angular na serwer testowy lub produkcyjny
Wielu początkujących deweloperów nie wie w jaki sposób ułatwić sobie pracę i zorganizować deployment swojej aplikacji. Często kończy się to tym, że po wygenerowaniu wersji produkcyjnej następuje ręczne przerzucenie plików z dysku na serwer za pomocą graficznego klienta FTP. Skoro tu trafiłeś zapewne zmęczyła Cię ta czynność i szukasz prostego sposobu na jego automatyzację... czytaj dalej a wszystkiego się dowiesz :)
Zaawansowane narzędzia - nie będą niezbędne
Przeglądając internet możemy pod hasłem "deployment tool" znaleźć bardzo dużo różnego rodzaju narzędzi które pomogą nam wysłać kod źródłowy aplikacji Angular na serwer testowy lub produkcyjny. Travis CI, Capistrano, Deployer, Jenkins to narzędzia i platformy które często się przewijają w internecie i StackOverflow. Część z tych rozwiązań wymaga serwera na którym zostaną uruchomione, nakładów pieniężnych gdyż nie są dostępne dla projektów komercyjnych lub niepotrzebnego nakładu w przypadku prostych aplikacji.
Na samym początku deweloperzy tworzą prywatne projekty, strony lub aplikacje które sami testują i publikują. Czy w takiej sytuacji niezbędne jest jakiekolwiek narzędzie do automatycznego deploymentu? Tak, ale można się ograniczyć do prostych rozwiązań.
SH/Bash + RSYNC
Rsync to program, który często wykorzystuję w swoich rozwiązaniach. Pozwala mi na bardzo prosty transport plików z jednej maszyny na drugą bez zbędnych dodatków. Wykorzystywany jest również w tworzeniu kopii przyrostowych, dlatego świetnie nadaje się do tego typu operacji.
Przykro mi, że dopiero teraz się o tym dowiadujesz ale poniższe rozwiązanie sprawdzi się tylko u programistów, którzy pracują na systemie Linux lub MacOS. Nie przejmuj się, Rsync można również zainstalować w systemach Windows - odsyłam do poradnika - a Sh/Bash z powodzeniem zastąpisz PowerShell. Dla tych bardziej ambitnych polecam zainstalować wirtualizację Ubuntu jednym kliknięciem w systemach Windows 10.
Zacznijmy od utworzenia prostego skryptu SH w głównym katalogu projektu. Nazwijmy go deploy.sh:
#!/bin/bash
ng build --prod
rsync -arvt ./dist remoteuser@remotehost:/var/www/remotedirectory
W drugiej linii tworzymy najnowszą wersję produkcyjną aplikacji Angular, zakładam że niczego nie modyfikowałeś w pliku angular.json i package.json. Z najnowszym CLI proces ten jest bardzo prosty, wystarczy wykonać polecenie ng build --prod
. Tu należy zwrócić uwagę, że katalog dist
nie zawsze znajduje się w głównym katalogu projektu. Lokalizacja katalogu wynikowego może zostać zmieniona w pliku angular.json
- sekcja options, parametr outputPath
.
Trzecia linia to finał naszego bardzo prostego narzędzia do wysyłania aplikacji na zdalny serwer i tu się na chwilę zatrzymamy, bo warto omówić parametry których użyłem do RSYNC:
- -a archive mode - pozwala zaoszczędzić trochę na ilości wysyłanych danych wstępnie je archiwizując na maszynie z której wykonujemy polecenie
- -r recursive - rekursywne kopiowanie katalogów
- -v verbose mode - dzięki temu zobaczymy więcej informacji w konsoli
- -t zmienia czasy modyfikacji wysłanych plików(na serwerze docelowym)
W przypadku, kiedy plików jest dużo, a upload jest trochę powolny można użyć parametru -W
, który pominie algorytm "delta-xfer", ale o tym możesz poczytać w dokumentacji :)
W kolejnym kroku nadajemy prawa do wykonania naszego nowego skryptu:
__aSyNcId_<_sEOmMwgP__gt; chmod +x ./deploy.sh
I już jesteśmy gotowi do pierwszego deploymentu :)
__aSyNcId_<_sEOmMwgP__gt; ./deploy.sh
Dlaczego RSYNC a nie SCP?
Dobre pytanie na które odpowiedź jest prosta. RSYNC jest bardziej optymalny. SCP kopiuje pliki liniowo, to takie polecenie cp
ale do użytku pomiędzy dwoma maszynami w sieci, nie posiada żadnych dodatkowych algorytmów, które przyspieszą kopiowanie. W przypadku aplikacji Angular nie wszystkie pliki ulegają zmianie, dlatego nie warto tracić czasu na kopiowanie wszystkiego. RSYNC takie funkcjonalności posiada, dlatego zalecam żeby używać właśnie tego narzędzia.
Tym artykułem chciałbym nie tylko Ci ułatwić pracę, ale również zachęcić do poznawania innych systemów operacyjnych niż tylko Windows. Sam system Linux czy MacOS posiada w swoim składzie narzędzia, które okazują się bardzo pomocne w życiu każdego programisty.