Nowoczesne wdrożenia dla Twoich witryn WordPress

Opublikowany: 2022-06-30

Jeśli jesteś podobny do mnie, Twoje pierwsze doświadczenie w przesyłaniu plików na serwer WWW miało miejsce za pośrednictwem internetowego menedżera plików, takiego jak cPanel lub klienta protokołu przesyłania plików (FTP), takiego jak Transmit lub Filezilla. Połącz się z serwerem, przeciągnij plik(i) nad i poczekaj na zakończenie przesyłania.

Łatwe, prawda?

Jednak gdy tylko zacząłem pracować z czymś bardziej złożonym niż statyczne pliki HTML, wdrażanie mojego kodu stało się znacznie bardziej złożone: co się stanie, jeśli przegapię plik, który jest wymagany przez innych lub średnik w globalnym dołączeniu i spowoduje to biały ekran cała witryna? Co się stanie, jeśli kluczowy krok zostanie pominięty podczas procesu?

Te problemy z „kodowaniem kowbojskim” nasilają się tylko w miarę angażowania się większej liczby osób, środowisk i zależności. W rezultacie coraz trudniej jest robić postępy podczas żonglowania wszystkimi ruchomymi częściami. Co gorsza, wydawanie kodu staje się wielką sprawą i stałym źródłem niepokoju.

Ponieważ nasze aplikacje, witryny i sklepy stają się coraz bardziej unowocześniane, powinniśmy również unowocześniać nasze wdrożenia. Od kontroli wersji po ciągłe dostarczanie, nowoczesny proces wydawania może złagodzić niepokój związany z wdrożeniami.

Śledzenie zmian za pomocą kontroli wersji

Pierwszym krokiem do odejścia od aktualizacji ad hoc i kodowania kowbojskiego jest objęcie witryny kontrolą wersji za pomocą narzędzia takiego jak Git.

Korzystanie z kontroli wersji oznacza, że ​​będziesz mógł zobaczyć, co się zmieniło, kto wprowadził zmiany, a nawet pracować nad wieloma zestawami zmian jednocześnie, korzystając z gałęzi. Dzięki temu praca nie jest nadpisywana, a wszelkie konflikty między plikami są wyraźnie wyróżnione.

Jeśli nie pracowałeś wcześniej z Git, nie martw się: napisaliśmy zarówno wprowadzenie do Git, jak i post o bardziej zaawansowanych przepływach pracy Git.

Decydowanie, co śledzić

Ponieważ przenosimy naszą witrynę pod kontrolą wersji, to, czego nie śledzimy, jest prawie tak samo ważne jak to, co robimy:

Ogólnie rzecz biorąc, kontrola wersji służy do śledzenia kodu źródłowego, a nie zasobów generowanych przez narzędzia lub procesy . Obejmuje to takie rzeczy, jak połączony/zminimalizowany CSS i JavaScript, zależności zewnętrzne itp. Łącznie nazywamy te elementy artefaktami .

Na przykład, jeśli używasz preprocesora CSS, takiego jak Sass, wygenerowane pliki CSS nie powinny być śledzone pod kontrolą wersji. Są one nie tylko łatwe do odtworzenia, ale także trudne do odczytania i stanowią wspólne źródło konfliktów scalania, gdy zaangażowanych jest wielu programistów.

Jeśli chodzi o zależności (biblioteki, wtyczki WordPress itp.), skorzystaj z narzędzi takich jak Composer i WPackagist zamiast łączyć kod, za który nie jesteś odpowiedzialny w swoim repozytorium.

Ponadto repozytorium Git nigdy nie powinno zawierać takich rzeczy, jak hasła, prywatne klucze SSH ani żadne inne poufne informacje, które byłyby uważane za tajne , ponieważ każdy programista z kopią repozytorium miałby wtedy te poufne informacje na swoich komputerach.

Strukturyzacja repozytorium

Podczas konfigurowania repozytorium Git dla witryny WordPress lub WooCommerce najlepiej jest traktować wp-content/ jako katalog główny repozytorium, ponieważ generalnie nie będziesz dotykać plików powyżej tego katalogu.

Wtyczki i motywy, których używa Twoja witryna, ale nie utrzymujesz kodu, powinny zostać załadowane przez Composer, ponieważ są to zależności zewnętrzne. Podobnie przetworzone pliki CSS i JavaScript należy wykluczyć za pomocą pliku .gitignore, ponieważ te artefakty zostaną zbudowane dla nas w ramach naszego procesu wydawniczego.

Mamy darmowy szablon repozytorium dostępny na GitHub, który pomoże Ci zacząć.

Wprowadzenie do CI/CD

Jeśli chodzi o wdrażanie oprogramowania, należy zrozumieć dwa ważne terminy: ciągła integracja (CI) i ciągłe dostarczanie (CD).

Te dwa terminy są ze sobą ściśle powiązane, do tego stopnia, że ​​często określa się je zbiorczo jako „CI/CD”, a ścieżka, przez którą przepływają nasze zmiany, staje się w ten sposób „rurociągiem CI/CD”. Ten potok zwykle przyjmuje następującą postać:

  1. Skompiluj wydanie: zainstaluj zależności (Composer, npm itp.), a następnie zbuduj artefakty (Webpack, Grunt, Sass itp.)
  2. Przetestuj kompilację: uruchom testy jednostkowe, sprawdź standardy kodowania, wykonaj analizę kodu statycznego itp.
  3. Wdróż wersję w co najmniej jednym środowisku

Ciągła integracja to proces ciągłego testowania naszego kodu, aby upewnić się, że zmiany nie zakłócają istniejącej funkcjonalności, dzięki czemu nasze nowe zmiany czysto integrują się z istniejącą bazą kodu. Za każdym razem, gdy wprowadzane są nowe zmiany, przeprowadzane są kontrole, aby upewnić się, że „nie psujemy kompilacji”.

Aby ciągła integracja była użyteczna, kontrole te muszą być zautomatyzowane. Na przykład, jeśli masz zestaw testów jednostkowych, możesz uruchomić ten zestaw testów za każdym razem, gdy otwierane jest nowe żądanie ściągnięcia, ostrzegając Cię o możliwych awariach, zanim kod trafi do środowiska produkcyjnego.

Ciągła integracja nie ogranicza się jednak do testów jednostkowych, ponieważ istnieje szereg testów „bez kodu”, które można uruchomić automatycznie w odniesieniu do kodu, w tym:

  • Sprawdzanie standardów kodowania (PHP_CodeSniffer, PHP Coding Standards Fixer)
  • Analiza kodu statycznego (PHPStan, Psalm)

Automatyczne uruchamianie tych kontroli przy każdym wypchnięciu zapewnia również, że cały kod jest uruchamiany przez te same kontrole, zapobiegając wydaniu kodu, który nie został przekazany.

Z drugiej strony Continuous Delivery to idea, że ​​powinniśmy być w stanie „dostarczyć” (wdrożyć) nasz kod w dowolnym momencie. Aby to osiągnąć, musimy mieć oskryptowany proces wdrażania, który jednym kliknięciem bezproblemowo przeniesie nasz kod do środowiska produkcyjnego.

Posiadanie skryptów wdrożeń oznacza, że ​​możesz wdrażać je regularnie i konsekwentnie ; każde wdrożenie powinno działać tak samo jak poprzednie. W rezultacie Twój zespół może wdrażać się bardziej regularnie, z większym poziomem pewności siebie i mniej obaw, że ktoś pominął krok po drodze. W przypadku niektórych zespołów nie jest niczym niezwykłym wdrażanie dziesiątek (a nawet setek) razy dziennie!

W zależności od witryny możesz nawet zajrzeć do „drugiej płyty CD”, Continuous Deployment ; jest to bardzo podobne do ciągłego dostarczania, ale w tym modelu każde wypychanie do oddziału jest wdrażane automatycznie. Może to być niezwykle wydajne w przypadku korzystania z rozgałęzionego schematu kontroli wersji (takiego jak Github Flow), ale może być niepożądane, jeśli musisz zaplanować okna wydań lub wykonać całą pracę w głównej gałęzi.

Wdrażanie witryny WordPress lub WooCommerce z CI/CD

Teraz, gdy znamy już podstawową terminologię, przyjrzyjmy się wdrażaniu typowej witryny WordPress lub WooCommerce:

W tym ćwiczeniu użyjemy Branch, narzędzia CI/CD zaprojektowanego z myślą o potrzebach programistów WordPress od tych samych osób, które stoją za WP Pusher. Co najlepsze, Branch ma wbudowaną obsługę wdrażania do Nexcess!

Aby rozpocząć, zarejestruj się w Branch, łącząc swoje konto GitHub, GitLab lub Bitbucket, a następnie tworząc swoją pierwszą witrynę.

Następnie będziemy chcieli skonfigurować wszystkie kroki niezbędne do zbudowania naszej witryny. Branch oferuje szereg „przepisów” na typowe akcje (instalacja zależności Composera, uruchamianie Webpacka itp.), ale daje nam również możliwość dodania dowolnej liczby niestandardowych kroków.

Po przedstawieniu kroków niezbędnych do zbudowania naszej witryny możemy przejść do następnego etapu naszego potoku: testowania.

Jeśli masz już zautomatyzowany zestaw testów dla swojej witryny, możesz po prostu powiedzieć Branchowi, aby uruchomił wszystkie niezbędne polecenia. Nawet jeśli nie masz jeszcze testów, Branch ułatwia dodanie lintingu, standardów kodowania i sprawdzania zgodności.

Teraz, gdy zainstalowaliśmy nasze zależności, zbudowaliśmy wszystko i przeszliśmy nasze testy, nadszedł czas, aby wprowadzić nasz kod do produkcji!

Branch zawiera przepisy na wdrożenie do Nexcess (a także innych głównych dostawców hostingu), a połączenie obu platform jest bezbolesne:

  1. Wybierz swoją witrynę w panelu Oddziału, kliknij „Ustawienia”, a następnie pobierz publiczny klucz SSH swojej witryny Oddziału
  2. Dodaj ten klucz publiczny do listy kluczy w portalu Nexcess

Gdy Branch będzie w stanie komunikować się z Twoją witryną Nexcess, możemy wybrać przepis wdrożenia „Nexcess” i podać kilka szczegółów:

  1. Nazwa hosta i nazwa użytkownika witryny (dostępne w portalu Nexcess na ekranie „Dostęp”)
  2. Katalog główny sieci, w którym wdrażamy. Jeśli nasze repozytorium git ma służyć jako katalog wp-content/, ta wartość powinna wynosić „public_html/wp-content”.
  3. Pliki, które chcemy wdrożyć (zazwyczaj domyślny „*” jest wystarczający)
  4. Gałąź git do wdrożenia w tym środowisku

Ustawienie „Git branch” jest szczególnie ważne, ponieważ pozwala określić różne wdrożenia dla różnych gałęzi. Na przykład możesz mieć gałąź „pomostową”, która jest wdrażana w środowisku pomostowym, umożliwiając testowanie zmian przed ich wprowadzeniem w życie.

Warto zauważyć, że Branch domyślnie używa modelu ciągłego wdrażania , w którym potok jest uruchamiany z każdym wypchnięciem do danej gałęzi. Jeśli wolisz bardziej ciągły model dostarczania (gdzie trzeba wykonać pewne ręczne działania), możesz rozważyć utrzymanie gałęzi „produkcyjnej”, która jest łączona tylko wtedy, gdy jesteś gotowy do wydania.

W tym momencie Branch powinien być skonfigurowany do budowania i wdrażania repozytorium git w Nexcess! Możesz uruchomić swoje pierwsze wdrożenie, klikając przycisk „Uruchom wdrożenie” na stronie „Potoki” Twojej witryny lub przechodząc do repozytorium Git.

Dostosowywanie procesu wydawania

Jedną z naprawdę fajnych funkcji Branch jest możliwość skonfigurowania dodatkowych kroków po pomyślnym wdrożeniu, takich jak automatyczne czyszczenie pamięci podręcznej obiektów witryny po wdrożeniu. Można to osiągnąć za pomocą przepisu WP-CLI w sekcji „Inne”.

Host i nazwa użytkownika będą generalnie takie same, jak w kroku wdrażania, i możesz połączyć dowolną liczbę poleceń.

Wniosek

Jeśli nadal zmagasz się z wybrykami związanymi z kodowaniem kowbojów i/lub wydaniami pełnymi niepokoju, spójrz na Branch i spraw, by wdrożenia były proste!