dploy vs. firebase deploy – jak łatwo opublikować stronę w internecie?

Post navigation

Kodowanie

dploy vs. firebase deploy – jak łatwo opublikować stronę w internecie?

Tworząc strony internetowe lub aplikacje każdy z nas szuka dobrego rozwiązania dla publikowania swoich prac w internecie. Jest wiele narzędzi, które to umożliwiają. Jedne mniejsze, drugie bardziej rozbudowane. Jednak tutaj chciałbym przybliżyć dokładnie dwa narzędzia, których używam na co dzień.

Czym są takie narzędzia?

Co jakiś czas wypadało by opublikować wersję demo dla klienta, opublikować nowe zmiany na produkcyjnym serwerze, zaktualizować stronę / aplikację / system. Szukałem czegoś prostego, żeby aktualizacje moich stron internetowych najszybciej jak to możliwe trafiały na serwer. Chciałem aby narzędzie było bardzo proste w konfiguracji, ponieważ nie chciałbym spędzać nad tym zbyt dużo czasu. Oczywiście trafiłem na systemy rozbudowane takie jak Jenkins czy Travis. Ale nie o to mi chodziło. Chciałbym, aby to było proste, a przynajmniej maksymalnie uproszczone. I w końcu znalazłem moich faworytów.

Jak to pomaga w produkcji oprogramowania?

Systemy do publikacji są bardzo istotne. Bardzo ułatwiają proces publikacji i natychmiast dostajemy demo, które można pokazać klientowi. Stary dobry klient FTP niestety wszystkiego za nas nie zrobi. W systemach do deploymentu główną ich zaletą jest to, że aplikacja czy strona nie przestają działać dopóki cały proces uploadu nowej wersji nie zostanie zakończony. Zabezpiecza nas to przed niechcianymi błędami podczas uploadu. Żaden plik nam wtedy nie umyka tak jak – często mi się to zdarzało – w przypadku uploadu przez zwykły FTP. Zdarzały się takie przypadki, że podgrałem nie te pliki co trzeba, nie te ścieżki, pojawiały się błędy w produkcyjnej wersji. I gdybym szybko tego nie wyłapał to była by katastrofa. Deploy poprzez wspomniane tu narzędzia (Dploy i Firebase) zajmuje od kilku do kilkudziesięciu sekund w zależności od wielkości aplikacji / strony.

dploy – jak działa i czym jest?

dploy jest to paczka NPM’owa którą instalujemy globalnie z poziomu konsoli

 npm install -g dploy 

Wszystkie operacje wykonujemy tu w konsoli. Dploy bazuje na naszym repozytorium GIT podpiętym do projektu. Aby zauploadować nasze nowe pliki na serwer trzeba zacommitować zmiany w projekcie, a następnie uruchomić komendę. Dploy tworzy sobie plik .rev, który służy mu do kontroli wersji pomiędzy serwerem FTP, a projektem lokalnym. Jest to swego rodzaju identyfikator, który podczas operacji porównuje z tym, który jest na serwerze FTP. Ale skąd dploy będzie wiedział gdzie zuploadować nową wersję?

Do naszego lokalnego projektu dodajemy plik o nazwie dploy.yaml, który wypełniamy odpowiednimi danymi uwierzytelnienia.

<br />
live:<br />
  scheme: ftp<br />
  host: samplehosting.pl<br />
  port: 21<br />
  user: user@samplehosting.pl<br />
  pass: password<br />
  check: true<br />
  branch: master<br />
  path:<br />
    remote: public_html/<br />
  exclude:<br />
    ['dploy.yaml', '.gitattributes', '.gitignore', '.rev']<br />

W pliku tym nie ma średników na końcu linii, a wcięcia są bardzo istotne ponieważ oznaczają zagnieżdżenia – podobnie jak w przypadku JSON lecz bez nawiasów i innych znaków. Jak widać na powyższym przykładzie będziemy się łączyć poprzez protokół FTP podobnie jak w przypadku innych klientów FTP. Określamy tu również branch z którego będzie robiony deploy. Zabezpiecza to przed publikacją wersji z jeszcze nie zmergowanych branchy gitowskich. Trzeba podać również ścieżkę gdzie aplikacja zostanie zuploadowana. Aby sprawdzić bazową ścieżkę najlepiej zalogować się na swój FTP docelowy i zobaczyć jaką ścieżkę od bazowej trzeba pokonać, aby dotrzeć do docelowego folderu. Np. jeśli użytkownik zaloguje się na ścieżkę “/domains/sampleapp.pl/” to ma do pokonania jeszcze “public_html” i opcjonalnie jeszcze jakiś folder. Dlatego podajemy path jako “public_html/” co spowoduje wypakowanie aplikacji właśnie do tego folderu. Exclude natomiast wyklucza nam pliki, których nie chcemy publikować.

Po dodaniu tego pliku do projektu musimy zacommitować nasze zmiany, a następnie uruchamiamy deploy za pomocą komendy

</p>
<p>dploy live</p>
<p>

Oczywiście możemy do pliku dploy.yaml dodać kilka innych docelowych serwerów poprzez skopiowanie całości powyższej reguły i wklejenie jej poniżej. Trzeba pamiętać jedynie o zmianie parametrów. Przy wykonywaniu operacji dploy zapyta nas czy jesteśmy pewni uploadu plików. Jeśli tak to deploy się odbywa. Następnie cieszymy się nową wersją na koncie FTP pod podaną wcześniej ścieżką. Jednaj trzeba pamiętać o nie publikowaniu samego pliku dploy.yaml ponieważ, jak pewnie każdy zauważy, zawiera wrażliwe dane naszego serwera. Warto zabezpieczyć się przed tym również od strony GITa, aby projekt był prywatny, a nie publiczny w takim wypadku.

Więcej na ten temat i dokumentacja znajduje się pod tym adresem: https://github.com/lucasmotta/dploy

Firebase deploy – jak działa i czym jest?

Firebase deploy jest czymś innym niż dploy. Jest to element pakietu Firebase, a bardziej szczegółowo – Firebase Tools. Tutaj wymagane jest utworzenie projektu Firebase w konsoli Google (console.firebase.google.com) oraz połączenie się z tym projektem i kontem Google. Wymaga to również inicjalizacji samego projektu lokalnie. Po tych operacjach można przystąpić do kodowania i samej publikacji zmian. Firebase Tools nie bazuje jednak na GIT’cie. Trzeba uważać kiedy i skąd uploaduje się aplikację. Możemy być na branchu, w którym mamy niechciane zmiany, takie tylko dla nas, chwilowe i opublikować je na serwerze produkcyjnym co zepsuje nam aplikację.

Pełną dokumentację na temat Toolsów i samego firebase deploy można przeczytać tutaj: https://firebase.google.com/docs/hosting/deploying

A sam deploy aplikacji ogranicza się do wykonania komendy:

 firebase deploy 

Co jest lepsze?

Niestety nie da się tego jednoznacznie stwierdzić. Oba rozwiązania służą do tego samego, ale mechanizmy się różnią. Przy dploy wystarczy nam konto FTP i domena podpięta pod hosting z tym FTP. W Firebase wystarczy nam założenie projektu w konsoli googlowskiej. Wybór odpowiedniego narzędzia zależy od rodzaju naszej aplikacji czy strony. Zleży też od tego czego oczekujemy i jak chcemy prezentować stronę czy aplikację, i dzięki którym narzędziom. Osobiście jeśli tworzę stronę www dla klienta korzystam z dploy, ponieważ klient z reguły ma już wykupiony dostęp do FTP i domeny lub chce mieć. Wtedy praca leci z górki. Jednak kiedy piszę aplikacje pod Firebase używam narzędzi do tego stricte przeznaczonych. Jednak można stawiać zwykłą stronę również na Firebase bez użycia bogatej funkcjonalności Firebase, a jedynie samego deploy. Dlatego wybór dodatkowo zależy od docelowego klienta, którym możesz być również Ty.