 No więc cześć wszystkim, nazywam się Piotr Kniadomski, pracuję w ClearCode i w PiWiC Pro, powtórzę to samo, bo tak wiem na slajdzie. Tak, jestem TechLidem, tam ClearCode możecie nie kojarzyć, trochę może to rynek Wrocławski, ale PiWiC Pro pewnie kojarzycie. Teraz darmowe rozwiązanie matomo, zmieniło nazwę, to jest taka alternatywa dla Google Analytics. Robimy nasze płatne rozwiązanie na tej bazie, polecamy działać. A dzisiaj bym chciał opowiedzieć o automatyzacji git deploymentu w WordPressie, albo może jeszcze na początek, może podnieście ręce osoby, które wiedzą w ogóle co to jest git i pracowały. Super, dobra, to nie będę wynikał w szczegóły, bo większość sali jednak wie. Więc robić to tak w PHP i co najdziękuję za uwagę, magia się skończyła, dobra szybka preska, wszyscy zadowoleni. Mieliśmy taki problem u nas w dziale, że chcieliśmy sobie zrobić automatyzację wdrożeń, żeby odzwierciedlać wszystkie zmiany, które wprowadzają nasi deweloperzy i które zostają zaakceptowane poly requestami do brancza dewelopa, żeby je odzwierciedlać na bieżąco, na żywo, automatycznie na maszynach stagingowych, czy tam testingowych. No i żeby to się działo ad hoc, w momencie jeżeli tylko coś jest domerżowywane do dewelopa, to z automatu leci sobie na serwery i w tym momencie klienci mogą sobie na żywo przeglądać wszystkie zmiany i to widzą. Nie muszą czekać raz, że ten poly request wiadomo, że to też musi przejść swoją drogę, że idzie poly request, review, jak jest okej, no to okej. Admin czy tam DevOps, ten podejmuje później cały system deploymentu, zaczyna wdrożenie tego, wrzuca to na stage, a jeszcze po drodze nie przejdzie review, więc odbijanie tego ticketa, kolejne comity itd. No to żeby uprosić tą całą ścieżkę w momencie, kiedy już jest domerżowywane ten comit do dewelopa, no to z automatu to leci na te maszyny testingowej i wszyscy to widzą i skracamy jakby ten proces, na który jest dosyć uciążliwy. No i założyliśmy sobie, że ponieważ używamy do naszych projektów gita, trzymamy nasze repozytoria, czy to na githubie, czy to na bitbakecie, w przeciwieństwie do tutaj pana poprawej podejście z FTP i przerzucanie tego kodu ręcznie, wystarcz po prostu się zalogować na serwer, już opatologicznie i sobie wpisać gitpul i wszystko jest robione z automatu, a nie przerzucanie, gubienie plików i ten, więc no nie, technologicznie idziemy jednak w stronę gita, zwłaszcza, że wielu programistów pracuje nad tym samym projektem, więc ułatwia to życie, no zresztą sami wiecie, że li korzystacie z gita. No i mamy to, te, te, te repozytoria gita i no i wymyślić sobie, że użyjemy kolejnej technologii, które udostępniają nam oba te narzędzia, czy to github, czy do bitbucket, czy gitlab, wszystkie one używają pokrewnych mechanizmów webhooków. Nie musicie tego czytać, to jest definicja z Wikipedia, żeby zapchać czymś slajd. A po krótce chodzi o to, że w momencie, kiedy coś zostaje wysyłane do, do naszego repozytorium hostowanego przez któregoś z tych providerów, no to on ma swój mechanizm, jak się go odpowiednio skonfiguruje, co ma pingować. On sobie wysyła sobie normalne requesty HTTP z informacjami o tym, co się zmieniło w naszym repozytorium, co zostało dodane, zmienione, co się zmierżowało, co nie, statusy, wszystko, wszystko tymi webhookami możemy sobie śledzić. No i możemy też sobie śledzić właśnie to, że coś zostało zmierżowane do dewelopa i jak to i co w związku z tym faktem zrobić. No i my chcielibyśmy wtedy, jeżeli się zmierżowało wszystko poprawnie, zdiploiować to na, na nasz staging testing. No i zrobiliśmy sobie research. Ok, wymyśliliśmy sobie coś, no ale na pewno nie jesteśmy piersi, którzy to wymyślili, bo przecież nic się nie wymyśla na nowo, już wszystko w internecie jest. No więc pierwsze, co robimy research, po co wymyślać koło na nowo, użyjmy czegoś, co już istnieje. No i znaleźliśmy sobie tam kilka projektów, w tym jeden bardzo obiecujący, który tutaj wypisałem, nazywa się git deploy, skrypcik w PHP, bardzo prosty, który, który powinien to za nas załatwić. To było wszystko spoko, tylko że to nie działa, więc no trochę tak, a, a, a wyglądało obiecująco. No i druga sprawa, że no jeszcze dodało go się tam poprawić, znować i, i, i mogło by to zafurkać, ale no nie było to dedykowane rozwiązanie też typowo pod WordPressa. Chcieliśmy mieć coś takiego, że, że to jest, to jest stricte przygotowane do WordPressa, nie do, do, do każdego projektu PHP-owego, chcieliśmy mieć dedykowane narzędzie. No więc zaczęliśmy custom development, tutaj taki ukłon w stronę Agnieszki, bo pytała kiedyś, ile zajmuje pisanie takich wtyczek u nas, ja te zrobiłem wyciąg z GD, 36 godzin zajęło nam, mniej więcej napisanie takich, takich wtyczek, jak widzicie, tam jest taki 38-komitów, 18-pulikwestów w międzyczasie. No i powstała sobie wtyczka, która to robi, czego użyliśmy, użyliśmy wszystkiego, co jest w sumie dostępne, out of the box z WordPressa, nie musieliśmy niczego w sumie szukać, bo wszystko jest z automatu. Jest API, API do pluginów, jest API do opcji, do settingsów, użyliśmy WP API do robienia endpointów, żeby odbierać i, i, i HTTP API, żeby wysyłać requesty z, w jedną, w drugą stronę do, do, do naszych operatorów, czy to jest GitHub, czy to tam Bitbucket i tak dalej. Użyliśmy WP Listable, klasy do, do listowania logów, tutaj zaznaczają, że to jest pre-made class, no jeżeli tego używacie, to, to fajnie, tylko że musicie mieć na uwadze, że akurat ta klasa jest prywatna w kodeksie, jest napisane, że nie powinno się z niej korzystać, bo w każdym momencie może być zmieniona i bez ostrzeżenia, no ale wszyscy jej używają, no bo fajnie się tym, korzysta się z chorowego mechanizmu WordPressa do listowania w taki sam sposób, jak, jak to WordPress robi w WP Adminie naszych danych. Tak, w db Delta do, do, do stworzenia dodatkowej tablicy w tabeli baz danych do logów, no i WP Mail do wysyłania powiadomień i do, po tym jak coś się udało, albo coś się skaszaniło na serwerze, jeżeli, jeżeli ten deployment poszedł dobrze albo źle. No ok, no i powstała sobie taka mała wtyczka, nazwa się cesta deploy, można ją ściągnąć sobie normalnie z oficjalnego Repozytorium WordPressa, bardzo prosta konfiguracja, podejemy, wybieramy sobie hosting z predefiniowanych trzech, tam jest teraz Github, Bitbucket, Stash i jest też zaszyty jakby, bo też było takie pytanie, a jest też zaszyty GitLab, tylko nie ma go na tej liście wymienionego, ponieważ on jest zakomentowany w kodzie, można go sobie odkomentować i zobaczyć czy działa, nie mieliśmy jak tego przetestować, więc, więc jest zakomentowany, ale nic nie stoi na przeszkodzie, żeby ktoś przetestował i dał nam znać, działał, nie zdążyliśmy. Ok, podaję się ścieżkę do binarki Githa, podaję się ścieżkę do Repozytorium Githa, które chcemy odświeżyć, przeważnie to jest ta instancja, na której właśnie konfigurujemy wtyczkę, ale nic nie stoi na przeszkodzie tak naprawdę, żeby ta instancja WordPressa, na której stoi wtyczka, żeby tak naprawdę deployowała coś na inne instancji, wystarczy tylko podać ścieżkę i żeby tylko Shell miał dostęp do tego katalogu. A więc można też tak rozwiązać. Podejmę brancz, który ma się spasować z tym webhookiem, czyli żeby tylko reagował na przykład na deployment na developer, a nie reagował na deploymenty, czy tam na merge na inne brancze. Podejmę token i tutaj w zależności, czy to jest Githa, co to się nazywa secret, w BitBucket nazywa się token, to jest w konfiguracji zaraz pokażę, po prostu trzeba ten losowy ciąg znaków, żeby powiedzieć do konfiguracji naszego hostingu, gdzie hostujemy repo, żeby zapewnić bezpieczeństwo tej transmisji. OK, URL naszego webhooka, on tutaj jest też generowany losowo, żeby nie dało się w niego wstrzelić jakieś robaki, się nie wstrzeliły w to i nie pingowały nam naszego endpointu. Do deploymentu e-mail, które chcemy powiadamiać o tym, czy się powiodło, czy się nie powiodło. Jest też możliwość przetestowania, czy odpowiednio server raz ma dostęp do samej ścieżki Githa i dwa, czy ma możliwość do wysyłania maili. Włącz włącz jeszcze. OK, po stronie naszego hostingu dawcy, w tym przypadku GitHuba, wchodzimy na odpowiednią zakładkę webhooks, wklejamy wygenerowanego URL'a, który był na slajdzie wcześniej, ustawiamy ten secret, który tam jest niniżej wykropkowany, i to wszystko. I to już zaczyna działać, podobnie jest w BitBakecie. Identyko jedyne co token podajemy jako parametr WRL-u, bo oni nie mają jakiegoś swojego mechanizmu do zapewnienia większej anonymowości tej komunikacji, więc tutaj token WRL-u podajemy. I na koniec konfiguracji naszego serwera, tego testingowego, stagingowego, musimy ustawić przeważnie uprawnienia do katalogu repozytorium, żeby nasz PHP miał możliwość wykonywania skryptów, szelu i uprawnienia do tych plików, do ich nadpisywania. Czyli właśnie ustawiamy sobie, to może być użytkownik WLW, to w zależności od serwera, przeważnie to jest WLW data, WLW, czasem inne juzerze przeważnie, jak jest apacz, to jest WLW data. Wygenerować klucz RSA, wbić ten klucz, żeby się mógł komunikować z gitem, no to już takie normalne rzeczy, jakie robimy, nawet jak konfigurujemy sobie gita lokalnie, to musimy to wykonać na zdalnym serwerze, żeby on miał po prostu dostęp do gita. Tak wyglądają logi już z przeprowadzonych deploymentów, czyli po prostu wszystko, co idzie, co jest szyte na konsolę, jest logowane po każdym deploymentie, jak widać, każda zmiana, która została wprowadzona na branczu, zostaje odzwierciedlona w logach i wszystko widzimy, jakie pliki zostały nadpisane, jakie dodane itd. I no i ewentualnie tutaj też się pojawią błędy, jeżeli coś pójdzie nie tak, które też zostaną wysłane zresztą mailem, że się deploy na przykład nie powie. Dodatkowo sami hostingodawcy po drugiej stronie jakby u siebie też logują to samo i to jest bardzo fajne, bo to jest screen z gita, z Bitbucketa i można sobie podejrzeć, co cały ten request, bo oni w formacie JSONa wysyłają, co zostało wysłane, kiedy, czy response był 200, czy może się odbił gdzieś tam od ściany, jakie zmiany były wysyłane itd. Więc można sobie na bieżąco zdebagować też, czy to jest wina po naszej stronie, czy po stronie może repozitorium samego i możemy to sobie podejrzeć również u naszych operatorów, repozitorium. I do tego wszystkiego to jest mega super i mega siła, że WordPress ma restowe API, wbudowane korowo. Dzięki temu ta komunikacja jest mega łatwa i mega prosta, wystarczyło użyć WPA API, stworzyć własny endpoint i nasłuchiwać na nim później i w drugą stronę wysyłać JSONowe pakiety i to działa jakby out of the box. Więc rest API jest super. No i teraz jeszcze chwila na bezpieczeństwo. Te tokeny, które tam wcześniej wam pokazywałem, to to jest taka krótka funkcja, która po prostu weryfikuje, czy token jest poprawny. W przypadku gita jest wyciągany z odpowiedniego nagłówka requestu. Github, żeby było trochę trudniej, wysyła informacje o tym, jakim funkcją skrótu zostało zakodowane token i trzeba najpierw wyciągnąć tę informację, jak to jest algorytm, użyć go, żeby rozkodować token i porównać go z zakodowanym tą samą funkcją skrótu tokenem, który ustawiliśmy w naszej wtyczce. Jeżeli się zgadzają, to znaczy się, że ten request jest faktycznie od github. W przybitbakecie po prostu hamsko porównujemy ten parametr token, który wklejaliśmy w wywołaniu requestu. Tutaj wszystko leci plain textem, więc trochę gorzej, ale liczymy na to, że i tak i tak wygenerowane URL losowo zapewni nam jakieś większe security, bo już tam jakieś boty też nie będą mogły sobie wbić tak łatwo i spingować tego adresu. Aha, no i tutaj jest jeszcze, fajnie jest jeszcze wylightlistować sobie tylko IPiki serverów, które mogą nas pingować, czyli w przypadku githuba webhooki stoją na raptem sześciu, chyba tylko w serwerach, więc bardzo łatwiej. I ta lista jest dostępna na githubie, więc można sobie po prostu tylko wylightlistować te sześcia IPików. W przypadku bitbaketa jest tam ich kilkanaście chyba, ale to też nie jest problem, żeby zaszyć, to po prostu nawet głupio w hata akcesie, że tylko z tych requestów, żeby odbierał komunikację na temu URLu i to wystarczy, żeby zapewnić nam bezpieczeństwo. Ok, no i dorzuciłem jeszcze jeden slajd, bo jeszcze jest taki problem jak, no dobra, a co z aktualizacjami? No bo mamy sobie, każdy z deweloperów ma sobie swoje środowisko lokalnie, sobie tam długie, długie coś sobie zmienia. No i teraz jak wysyła sobie to do dewelopa, marzuje, to idzie na te wszystkie serwery, no ale jeszcze są aktualizacje WordPressa, które w międzyczasie mogą się dziać i też chcielibyśmy, żeby były odzwierciedlane automatycznie. Ba, chcielibyśmy też, żeby nie musiał tego robić ten programista, biedny, który tam sobie koduje swoją, swój projekt i no i raz, że on żeby tego nie musiał robić i żeby nawet nie mógł tego robić, bo jak jeden programista coś zmieni, będzie to domerczowywał, drugi zmieni po czasie, a nie daj Boże jeszcze w międzyczasie wyjdzie nowa wersja wtyczki i te zmiany się nie zmierdziłem automatycznie, no to później jest problem z konfliktami na gicie, no i trzeba tam cofać, jakieś rebej zrobić i się z tym męczyć. No więc wymyśliliśmy, no okej, no to może zastosujemy takie same podejście i zrobimy taki trochę reverse engineering i żeby jeden z naszych WordPressów robił jako taki developer, który tylko on może robić aktualizację i robi sobie aktualizację, po czym wrzuca to sobie na odpowiedniego brancza z aktualizacjami, które później zdomerczowywane do naszego dewelopa i wszyscy są fajnie, sieciaszczą, bo mają wszyscy zawsze aktualnego WordPressa. WordPressa wtyczki i motywy tłumaczenia, wszystko co w sumie można zrobić automatycznie z aktualizacji WordPressa, żeby się działo samo znowu, znowu magia. Tak brzmi znajomo, no właśnie wykorzystaliśmy mechanizm aktualizacji WordPressa, który już jest w niego wbudowany. Jedyne co musieliśmy zrobić, no to napisać identyczną wręcz wtyczkę, tylko która będzie teraz zamiast pulować, zamiast ściągać serwera dane, no to te aktualizacje wysyłać na repozytorium. No więc podobnie konfigurujemy ścieżkę do gita, katalog, który obserwujemy, który chcemy wysyłać, interwał czasowy, jak często chcemy sprawdzać, czy są nowe aktualizacje, znowu maile, czy się powiodło. No i wysyłamy, za każdym razem jak się zaktualizuje nasz WordPress, z co minutę tutaj jest ustawiony interwał, jest sprawdzane, czy jest jakaś nowa wtyczki, motywu samego WordPressa, tłumaczeń, jakichkolwiek, jest aktualizowany i wysyłany jest git pushem po prostu na serwer. A czy, no dobra, proces jest trochę bardziej skomplikowany, bo on jeszcze sobie tam sprawdza w międzyczasie, czy na pewno nikt nie wysłał takich zmian, czy robi sobie fetcha, czy na pewno już nie ma tych zmian, czy ktoś przypadkiem właśnie nie zaktualizował WordPressa i czy tam nie ma już tych zmian na repo, no ale po krótce po prostu pcha te aktualizacje do repo, które później są domarzowywane do gałęzi tej testingowej dewelopa. No i podsumowując, tak, wielka miłość, git plus te hooki, które załatwiają całą sprawę i to jest w sumie, po krótce wszystko.