Osom Studio

Wstęp do korzystania z Buddy.Works

Maciek Palmowski

Tradycyjny sposób deploymentu

  • Bazuje bardziej na kalendarzu niż na aktualnym postępie w kodzie
  • Częściej wymaga manualnej ingerencji
  • Dzień release'u jest istnym armaggedonem

Continuous integration / Continuous deployment

  • Cały czas bazujemy na aktualnej wersji kodu - nie czekamy na merge związany z releasem
  • Deploymenty są ciągłe - nowe ficzery lądują na serwerze
  • Automatyzjacja procesów - kompilacja zasobów, testy etc

Czego potrzebujemy?

  • System kontroli wersji - np. GIT
  • Odpowiednio przygotowany kod
  • Oprogramowanie takie jak Buddy.Works, Jenkins, CircleCI etc

Czemu akurat Buddy.Works?

  • Jest bardzo wygodny
  • Ciągle jest rozbudowywany o kolejne ficzery
  • W porównaniu z konkurencją ma najlepszą obsługę FTP/SFTP
  • Miło jest wesprzeć rodaków

Podział

Zmienne globalne

Projekty

Projekt / kod

Projekt / zmienne projektowe

Projekt / pipelines

Projekt / pipeline / actions

Projekt / pipeline / filesystem

Projekt / pipeline / zmienne lokalne

Pliki z repozytorium, a filesystem

  • Pliki w repozytorium zawsze zmieniamy tylko naszymi pushami
  • Filesystem to pliki z repozytorium przetowrzone przez nasze akcje

Przykład

Katalog pluginów w repozytorium

Przykład

Akcja

                                    
composer update

Przykład

Filesystem

Zmienne środowiskowe

  • Są do przechowania danych taki jak np. nazwa motywu, url etc
  • Można jest następnie użyć we wszystkich pipelinach
  • Obowiązuje dziedzicznie i możliwość "przeciążenia"...
  • ... ale nie w przypadku zmiennych globalnych - ich nadpisanie zawsze działa globalnie

Zmienne środowiskowe - jak używać

                                    
echo DB_NAME=${db_name} > .env
echo DB_USER=${db_user} >> .env
echo DB_PASSWORD=${db_password} >> .env
echo DB_HOST=${db_host} >> .env

Rodzaje deploymentów

  • Wszystko odbywa się w Buddym
  • Wszystko odbywa się na serwerze
  • Atomic Deployment

Rodzaje deploymentów / wszystko odbywa się w Buddym

Zalety:

  • Zadziała na każdym serwerze, na którym jest FTP / SFTP
  • Mamy pełną kontrolę nad wersjami wszystkich komponentów
  • W przypadku błędu deployment po prostu się nie uruchomi

Rodzaje deploymentów / wszystko odbywa się w Buddym

Wady:

  • Musimy przerzucić sporo plików - możliwy WSOD
  • Trwa najdłużej

Rodzaje deploymentów / wszystko odbywa się po stronie serwera

Zalety:

  • Jest bardzo szybki

Rodzaje deploymentów / wszystko odbywa się po stronie serwera

Wady:

  • Musimy przygotować wszystkie narzędzia potrzebne do builda na serwerze
  • ... musimy je akutalizować
  • Jak coś pójdzie nie tak z buildem, dostaniemy WSOD

Rodzaje deploymentów / atomic deployment

Zalety:

  • Zero downtime
  • Bardzo szybkie przywracanie starych wersji

Rodzaje deploymentów / atomic deployment

Wady:

  • Wymaga serwera zarządzalnego
  • Najtrudniejszy w konfiguracji
  • Sam deployment nie jest najszybszy - zawsze musimy wypychać wszystkie pliki

Przykład - SasquatchWP

Stworzenie nowego projektu

Dodanie webhooka

Stworzenie pipeline

Stworzneie pipeline

Wybranie akcji

Akcje

.htaccess i .env

                                        
echo DB_NAME=${db_name} > .env
echo DB_USER=${db_user} >> .env
echo DB_PASSWORD=${db_password} >> .env
echo DB_HOST=${db_host} >> .env
echo DB_PREFIX=${db_prefix} >> .env
echo WP_ENV=${wp_env} >> .env
echo WP_ALLOW_MULTISITE=false >> .env
echo MULTISITE=false >> .env
echo SUBDOMAIN_INSTALL=false >> .env
echo WP_HOME=http:\/\/${folder}.osomapps.com >> .env
echo WP_SITEURL=http:\/\/${folder}.osomapps.com/wp >> .env
echo "AUTH_KEY='3/(\$\$OUh3L;-cpllF]7?[gR4:>_dd9uvZmILX2le(MJFE[4B1Dc4(bKlo43,!id+\'" >> .env
echo "SECURE_AUTH_KEY='sZEwvh_qvQC#s!quc7Q{soy{ZsUy507U#;c5,dN\$C4]B[%h[F?k6o.i5r4QrPnX+'" >> .env
echo "LOGGED_IN_KEY='OVgt_bslu-oym*^!LE!CZz[y)fNeE:X\$uK85z_Uk9I)wkoOp_:T;c6WXGkR\$VCL*'" >> .env
echo "NONCE_KEY='*&b_::B@m(aH|v(Y5.uAiATXK2glPO#5qRS|iRWr&0S[@VayQ_{t&hFpry*!Vyyk'" >> .env
echo "AUTH_SALT='m:hrl7x:=JqZjQ;b}a;]U\$6lJ}F!GomnA|d7}m\`J3g[^;.^ls@cA88CE+gsA4e*8'" >> .env
echo "SECURE_AUTH_SALT='EIYK)4s*3=>/IU,T^uP&E|yyc/Kq)ElYeP>_E+.ke3sl1|5v*6ZHSqV{Ntt!g61'" >> .env
echo "LOGGED_IN_SALT='!^zY0-g^o@[k\`z9UB/jm;VX_g}7i*lD{BGVL[/XCeu9>&m1IPuj$>JCUUA.6A[L;'" >> .env
echo "NONCE_SALT='&P/?+S3S_bs[D!+0&J*!]gkU?yK[*{UTl032Ia)YIe8RC_eVWn)4dx\`qxeBP]={'" >> .env
echo "ACF_PRO_KEY=${ACF_PRO_KEY}" >> .env
#.htaccess
echo "AddType application/x-httpd-php71 .php" > .htaccess
echo "RewriteEngine on" >> .htaccess
echo "RewriteCond %{HTTP_HOST} ^(www.)?${folder}.osomapps.com$" >> .htaccess
echo "RewriteCond %{REQUEST_URI} !^/web/" >> .htaccess
echo "RewriteCond %{REQUEST_FILENAME} !-f" >> .htaccess
echo "RewriteCond %{REQUEST_FILENAME} !-d" >> .htaccess
echo "RewriteRule ^(.*)\$ /web/\$1" >> .htaccess
echo "RewriteCond %{HTTP_HOST} ^(www.)?${folder}.osomapps.com$" >> .htaccess
echo "RewriteRule ^(/)?\$ index.php [L]" >> .htaccess

composer

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

npm

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

Upload

Przykład - Uptimerobot

Przykład - Uptimerobot

Przykład - Uptimerobot

Przykład - Uptimerobot

Dobre praktyki

  • Opisujmy dobrze co robi pipeline - development, production etc
  • Wypełniajmy pole od adresu strony docelowej

Bezpieczeństwo

O czym warto pamiętać:

  • CI / CD jest dość bezmyślne - uważajmy co wrzucamy
  • Szyfrujmy zmienne środowiskowe które tego wymagają
  • Jeżeli damy userowi możliwość podejrzenia filesystemu albo edycji pipeline będzie mógł podejrzeć wszystkie zaszyfrowane zmienne

Jak przyspieszyć deployment

  • Nie wrzucajmy zbędnych plików - np node_modules
  • Poprawnie wykorzystujemy w npm czy composer różnicę między dependency a dev-dependency
  • Warunkowe odpalanie poleceń - coś co musimy wprowadzić

Pytania?

Kto następny?