Pandify - porady jak projektować strony internetowe, darmowe materiały, liczne inspiracje web design.

Buddy.Works + Bedrock = ♥

Artykuł pojawił się 22.11.2017, autorem jest Maciek Palmowski i wpadł do kategorii WordPress

Pisałem już kiedyś o Buddy.Works – usługa spodobała mi się, ale nie zdecydowałem się wtedy na rezygnację z DeployBot. Teraz nie wyobrażam sobie życia bez Buddy’ego. W tym artykule opiszę jak skonfigurować poprawnie usługę pod deployment Bedrocka (i Timbera).

Wymagania

Jako, że większość naszych klientów lubi shared hosting, to cały proces musi być tak przygotowany, żeby działał wszędzie. Powoduje to, że nie będziemy nic odpalać na serwerze – wszystko wykonamy w Buddy.Works, a na serwer prześlemy przetworzone pliki.

Co musimy przygotować?

  1. Uzupełnić zmienne środowiskowe – dzięki temu potem możemy tylko zmieniać ich wartości, a mechanizm będzie ciągle taki sam
  2. Na bazie zmiennych środowiskowych utworzyć pliki .htaccess oraz .env
  3. Zainstalować WordPress oraz pluginy za pomocą composer
  4. Zainstalować potrzebne skrypty poprzez composer oraz pakiety npm w motywie oraz odpalić jakiegoś gulpa, grunta czy co tam używamy
  5. Przesłać na serwer za pomocą FTP czy SFTP
  6. Wysłać powiadomienie jeżeli wszystko się powiodło lub nie – my używamy do tego Slacka

Zmienne środowiskowe

Dzięki zmiennym środowiskowym ograniczamy ilość pracy do minimum. Wystarczy poświęcić te 2 minuty na wypełnienie wszystkich pól i mieć gotowy podkład na kolejne środowiska. My używamy:

folder – nazwa katalogu oraz subdomeny na środowisku developerskim – tej zmiennej używamy tylko w środowisku developerskim

wp_env – definiujemy czy to środowisko developerskie, stagingowe czy produkcyjne

db_name – nazwa bazy danych

db_prefix – prefix

db_user – nazwa użytkownika bazy danych

db_host – host bazy danych

db_password – hasło do bazy

theme_name – katalog, w którym znajduje się motyw

Plik .htaccess oraz .env

Mając zmienne z punktu wyżej pozostaje nam wygenerować pliki .env oraz .htaccess

W wersji produkcyjnej wygląda to troszkę inaczej

Po prostu nie używamy zmiennej ${folder}.

Oczywiście za każdym razem wypełniamy salts zgodnie z zaleceniami – https://roots.io/salts.html .

Composer

Zaczynamy od tego co wymaga sam Bedrock – czyli instalacji WordPress’a oraz pluginów.

Dodajemy więc Run PHP tasks & tests a tam:
composer update

Krok poniżej u każdego może wyglądać inaczej. U niektórych może być też zupełnie pominięty.

My stosujemy połączenie Foundation oraz Timbera. Żeby to wszystko zainstalować musimy najpierw poprawić odrobinę poprzedni krok:

composer update
cd web/app/themes/${theme_name}/
composer update

Czyli najpierw instalujemy WP i pluginy, a następnie zmieniamy folder i instalujemy pakiety potrzebne do działania samego motywu (Timber oraz zależności).

Kiedy to zrobimy, dodajemy kolejny krok – Build your Node.js App:

cd web/app/themes/${theme_name}/
npm install
npm run build

 

Dzięki niemu wchodzimy do odpowiedniego katalogu i odpalamy npm installoraz npm run build.

Wgranie danych

Pozostaje nam już tylko wrzucić pliki na serwer. Poza wpisaniem danych dostępowych musimy zdecydować czy chcemy wgrać pliki bezpośrednio z repozytorium (nieprzetworzone) czy z systemu plików danego pipeline’a. Biorąc pod uwagę poprzednie kroki – zależy nam na tym drugim wariancie.

Na samym końcu pozostaje nam podać listę plików, których nie chcemy przesyłać – w moim przypadku to:

Oczywiście w zależności od tego co stosujemy ta lista może się odrobinę różnić.

Komunikaty

Jak wspomniałem na wstępie – żeby ograniczyć bałagan w mailach wszystkie komunikaty od Buddy.Works lądują w specjalnym kanale slackowym o nazwie#buddy-works.

Za każdym razem kiedy deploy przejdzie (lub nie) pojawia się tam komunikat.

Buddy.Works komunikaty

 

Wady tego rozwiązania

Są dwa:

  • hasło do bazy danych – nawet jeżeli zaklikamy pole encrypt, to każdy kto ma troszkę większe uprawnienia może zajrzeć w filesystem i zobaczyć jak ono wygląda. Problem można rozwiązać dwojako. Albo przestrzegać karnie uprawnień userów albo nie generować pliku .env, tylko wgrywać go samodzielnie. Za często się on nie zmienia, więc można sobie pozwolić na coś takiego.
  • pierwsze wgranie plików – jak wspominałem – jest to wariant, który zadziała na każdym hostingu z odpowiednią wersją PHP i wszystko wykonuje się po stronie Buddy.Works – co za tym idzie WP z kilkoma pluginami za pierwszym razem będzie się wgrywał około 15-20 minut. Można by to szybciej zrobić przez odpalanie komend bezpośrednio na serwerze, ale niestety nie wszędzie jest to możliwe.

Reasumując

Mimo tych dwóch drobnych wad taki pipeline jest trzonem wszystkich nowych serwisów, które tworzymy. Dzięki temu że różnią się tylko zmiennymi środowiskowymi, stawianie kolejnych stron zajmuje tylko moment i nie wymaga zbyt dużo pracy.

Maciek Palmowski

Jestem programistą - hobbystycznie i zawodowo (pracuję w Spiders.Agency). Kiedy jednak odejdę od klawiatury jeżdżę na rowerze, biegam albo gram w gry.

Bądź na bieżąco!

Jeżeli chcesz otrzymywać informacje o najnowszych wpisach na blogu Pandify.pl zapisz się do naszego newslettera za pomocą poniższego formularza. Obiecujemy nie wysyłać nic więcej.