Ciągłe wdrażanie i kontrola wersji WordPress za pomocą Bitbucket

Dobra ludzie. Czas przyznać się.

Jeśli jesteś kimś podobnym do mnie, spędziłeś pierwszą część swoich lat rozwoju WordPressa na „kodowaniu kowbojskim” — to znaczy na dokonywaniu szaleńczych zmian w aktywnych witrynach, pilnym testowaniu i uruchamianiu ich za pomocą FTP, co często skutkuje 500 komunikatami o błędach wewnętrznego serwera i wszystkie przerwy w witrynie są widoczne dla cenionych użytkowników.

Chociaż było to absolutnie ekscytujące, gdy adrenalina pompowała przez twoje palce, uderzając w ten zapomniany średnik, w witrynach z więcej niż 0 użytkownikami (którzy faktycznie zauważyli przestój), zaczęłoby to stawać się problemem. Jeśli drzewo upada i nie ma nikogo, kto mógłby je usłyszeć, czy wydaje dźwięk? Zależy od teorii ludzkości, pod którą się zgadzasz.

Jeśli jednak witryna ulegnie awarii i ktoś ją zobaczy, z pewnością wyda dźwięk.

Ciągłe wdrażanie WordPressa zostało wykonane źle

Wejdź na strony postojowe, zduplikuj instalacje WordPressa (przynajmniej teoretycznie), w których można wprowadzić zmiany, a następnie wprowadź je ponownie na aktywnej stronie, gdy wszystko zostanie potwierdzone, że działa. Chociaż to uspokoiło odwiedzających, zaczęło powodować hałas. Nagle musieliśmy śledzić dwie witryny, upewnić się, że kod jest między nimi ręcznie synchronizowany, i ponownie przetestować wszystko, aby upewnić się, że działa na działającej witrynie. Długie, niechlujne listy „pamiętaj, aby zmienić to na żywo” i „przełącz to na stronie testowej przed skopiowaniem kodu”, były co najmniej denerwujące. Kopie zapasowe tego systemu również były koszmarem — mnóstwo folderów o nazwach „mój-motyw-inscenizacja-1” i „mój-motyw-na żywo-przed-zmianą-menu-3” i tak dalej.

Musiał być lepszy sposób i był.

Był Git, który daje programistom doskonałą kontrolę nad źródłami i inne funkcje. Korzystanie z kontroli wersji dla instalacji WordPressa natychmiast przyspieszyło i oczyściło programowanie, ponieważ godziny nie były już spędzane na tworzeniu kopii zapasowych w systemie dla programistów, ale w rzeczywistości na kodowaniu. Zmiany zostały zapisane i wreszcie mogłem dodać znaczące wiadomości do mojej pracy, światy różniące się od „mój-temat-4-v2”.

Chociaż baza kodu była znacznie czystsza, problem nadal dotyczył rzeczywistych wdrożeń i upewnienia się, że dana witryna korzysta z najnowszego kodu — wprowadź możliwość wystąpienia błędu ludzkiego. Nadal poleganie na ręcznym przesyłaniu FTP nadpisującym poprzedni kod nie było zbyt dobre. Chociaż istniały inne usługi CI/CD, wiele z nich było kosztownych i wymagało dużej ilości ustawień — rekonfiguracja serwera, poleganie na jeszcze innej usłudze nawet w przypadku najprostszej witryny internetowej, poznanie całego „sposobu działania” innej usługi i wszystko inne. idiosynkrazje, które się z tym wiążą.

Chociaż podobne konfiguracje do tego samouczka można wykonać za pomocą GitHub/GitLab i innych usług, wcześnie umieściłem swoje jajka w koszyku Atlassian ze względu na ich bezpłatne prywatne repozytoria (co było tylko niedawną ofertą z GitHub). Gdy Bitbucket wprowadził swoje usługi Pipelines i Deployments , umożliwił automatyczne wdrażanie nowego kodu w witrynach pomostowych lub produkcyjnych (lub w dowolnej innej witrynie pośredniej) bez ponownego przesyłania przez FTP lub korzystania z usługi zewnętrznej. Deweloperzy mogli teraz wykorzystywać wszystkie wartości kontroli źródła w swoich programach WordPress i natychmiast wysyłać te zmiany do odpowiednich miejsc docelowych bez dodatkowych kliknięć lub naciśnięć klawiszy, ze statusem wszystkiego widocznym za pośrednictwem jednego pulpitu nawigacyjnego. Gwarantuje to, że wszystko pozostaje zsynchronizowane i na pierwszy rzut oka możesz dokładnie wiedzieć, jaki kod działa w każdej witrynie. Ponadto ceny za minuty kompilacji Bitbucket są niezwykle przystępne — z 50 minutami za darmo miesięcznie i opcją planu „Bezpłatne z nadwyżkami”.

Trochę czasu zajęło ustalenie, jak najlepiej wykorzystać gałęzie i inne funkcje kontroli źródła w tym nowym modelu oraz szczegóły konfiguracji Bitbucket Pipelines. Oto proces, którego używam do uruchamiania nowych projektów WordPress. Nie będę zagłębiał się w wszystkie sedno sprawy związanej z konfiguracją instalacji git i WordPress, ponieważ świetne zasoby są w zasięgu wyszukiwarki Google. Ostatecznie przepływ treści będzie wyglądał mniej więcej tak:

Procedura wdrażania Alexa Green WordPress

Opisane tutaj kroki należy wykonać w razie potrzeby:

Na serwerze klienta

Skonfiguruj domenę dla aktywnej witryny (np. clientite.com) i subdomenę do przemieszczania (np. staging.clientsite.com).

Zainstaluj WordPressa zarówno w aktywnej witrynie, jak iw tymczasowej subdomenie. Można to zrobić za pomocą cPanel/Softaculous (jeśli hosting klienta to posiada) lub pobierając z wordpress.org. Upewnij się, że istnieją oddzielne bazy danych odpowiednio na żywo i pomostowe.

Na Bitbucket.com

Skonfiguruj nowe repozytorium. Dołącz plik .README, aby zacząć działać.

W repozytorium wybierz Ustawienia > Potoki > Ustawienia , a następnie zaznacz Włącz potoki .

W Ustawienia > Potoki > Zmienne repozytorium wprowadź następujące dane:

 Name: FTP_username Value: The client FTP username

 Name: FTP_password Value: The client FTP password 

Wróć do Pipelines > Settings i kliknij przycisk Konfiguruj bitbucket-pipelines.yml . Wybierz PHP jako język na następnej stronie. Będziesz chciał użyć czegoś takiego jak poniższy kod. Upewnij się, że zastąpiłeś wersję PHP dowolną używaną na serwerze klienta, a adresy URL/serwery FTP na rzeczywiste adresy URL/serwery FTP witryny klienta (produkcyjne i pomostowe).

 image: php:7.1.29 pipelines: branches: master: - step: name: Deploy to production deployment: production script: - apt-get update - apt-get -qq install git-ftp - git ftp init --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com main-dev: - step: name: Deploy to staging deployment: staging script: - apt-get update - apt-get -qq install git-ftp - git ftp init --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com/staging.clientsite.com 

Kliknij Zatwierdź plik . Konfiguracja Pipelines zostanie teraz zatwierdzona i uruchomiona.

Jeśli wszystko zostanie pomyślnie wdrożone, wróć i edytuj plik bitbucket-pipelines.yml (możesz tam przejść przez Pipelines > Settings i View bitbucket-pipelines.yml ). Będziesz chciał zastąpić oba miejsca, w których jest napisane git ftp init , na git ftp push i save/commit. Zapewni to przesyłanie tylko zmienionych plików, oszczędzając w ten sposób minuty na kompilację. Twój plik bitbucket-pipelines.yml powinien teraz brzmieć:

 image: php:7.1.29 pipelines: branches: master: - step: name: Deploy to production deployment: production script: - apt-get update - apt-get -qq install git-ftp - git ftp push --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com main-dev: - step: name: Deploy to staging deployment: staging script: - apt-get update - apt-get -qq install git-ftp - git ftp push --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com/staging.clientsite.com 

Dodaj gałąź o nazwie main-dev .

Na Twoim lokalnym komputerze

Sklonuj repozytorium do pustego katalogu, którego chcesz użyć do instalacji lokalnej. Sprawdź gałąź main-dev .

Skonfiguruj lokalną instalację WP w tym katalogu. Jest do tego wiele narzędzi — Local by Flywheel, MAMP, Docker itp. Upewnij się, że wszystko jest takie samo (wersja WordPress, wersja PHP, Apache/Nginx, itp.) jak to, co działa na serwerze klienta.

Dodaj plik .gitignore , który wygląda mniej więcej tak. Zasadniczo chcemy, aby Git ignorował wszystko oprócz wp-content (aby zapobiec problemom z instalacją między instalacjami). Możesz także dodać własne reguły ignorowania dużych plików kopii zapasowych oraz ikon utworzonych przez system i plików DS_Store.

 # Ignore everything * # But not .gitignore !*.gitignore # And not the readme !README.md # But descend into directories !*/ # Recursively allow files under subtree !/wp-content/** # Ignore backup files # YOUR BACKUP FILE RULES HERE # Ignore system-created Icon and DS_Store files Icon? .DS_Store # Ignore recommended WordPress files *.log .htaccess sitemap.xml sitemap.xml.gz wp-config.php wp-content/advanced-cache.php wp-content/backup-db/ wp-content/backups/ wp-content/blogs.dir/ wp-content/cache/ wp-content/upgrade/ wp-content/uploads/ wp-content/wflogs/ wp-content/wp-cache-config.php # If you're using something like underscores or another builder: # Ignore node_modules node_modules/ # Don't ignore package.json and package-lock.json !package.json !package-lock.json

Zapisz i zatwierdź .gitignore .

Wprowadź zmiany i odpowiednio zatwierdź.

Za każdym razem, gdy zdecydujesz się na main-dev, uruchomi to przesłanie FTP do strony testowej. Za każdym razem, gdy zobowiążesz się do opanowania, uruchomi się przesłanie FTP do witryny produkcyjnej. Zwróć uwagę, że będzie to wykorzystywać minuty na kompilację, więc możesz chcieć wykonać większość lokalnych zmian na gałęzi poza main-dev, a następnie połączyć się z main-dev, gdy skończysz na dany dzień.

Połączenie głównego dewelopera z masterem wprowadzi wszystkie zmiany w inscenizacji na żywo. Możesz sprawdzić stan potoków i wdrożeń w repozytorium na Bitbucket.org.

Synchronizowanie baz danych WordPress w różnych instalacjach

Pamiętaj, że powyższe zsynchronizuje tylko pliki (motywy, wtyczki itp.). Synchronizowanie bazy danych między produkcją a przemieszczaniem staje się inną sprawą, ponieważ często klienci wprowadzają zmiany w działającej witrynie, które nie są odzwierciedlane w witrynie tymczasowej i na odwrót.

Istnieje kilka opcji synchronizowania baz danych w instalacjach WordPress. Tradycyjnie możesz aktualizować bazy danych poprzez importowanie/eksportowanie przez phpmyadmin . Jest to jednak trudne, ponieważ nie może zaktualizować niektórych rzeczy, które wymagają aktualizacji, takich jak permalinki w treści postów. Korzystając z tej metody, ulubionym narzędziem jest wtyczka Velvet Blues Update URLs, której można następnie użyć do wyszukiwania/zamieniania dowolnych wystąpień adresu URL starej witryny (np. https://staging.clientsite.com) na adres URL nowej witryny ( np. https://witryna_klienta.com). Możesz również użyć tego ze ścieżkami względnymi i ciągami. Ta metoda kończy się pozostawiając wiele miejsca na błąd ludzki — jeśli zastąpiony ciąg jest błędnie napisany, może to spowodować awarię całej witryny i niemożność korzystania z wtyczki/dostępu do pulpitu nawigacyjnego.

Chociaż wtyczka, taka jak All-in-One WP Migration, oferuje funkcję wyszukiwania/zamieniania po wyjęciu z pudełka i jest niezwykle przyjazna dla użytkownika, ale także przenosi pliki, cofając w ten sposób wartości całego naszego przepływu pracy Pipelines. Dodatkowo, ponieważ ponownie importuje wszystkie wp-uploads, może to skutkować ogromnymi plikami i czasami ładowania (w związku z tym nie nadaje się do przenoszenia zmian między instalacjami). Taka wtyczka jest najlepiej zarezerwowana do tworzenia kopii zapasowych całej witryny w celach archiwalnych/bezpieczeństwa.

VersionPress wydaje się interesującym rozwiązaniem, ale nie zostało jeszcze sprawdzone w wielu środowiskach produkcyjnych. Na razie wtyczki takie jak WP Sync DB lub WP Migrate DB Pro wydają się najlepszymi rozwiązaniami do zarządzania bazą danych. Pozwalają na ściąganie/przepychanie baz danych między instalacjami, dając jednocześnie opcję automatycznej aktualizacji adresów URL i ścieżek. Mogą migrować tylko niektóre tabele, takie jak wp_posts tylko dla treści postów, nie tracąc czasu na ponowne importowanie użytkowników i ustawień całej witryny. Lubię zawsze pobierać dane z życia, aby upewnić się, że żadne dane produkcyjne nie zostaną nadpisane. Oto przykładowa konfiguracja, jeśli używasz WP Sync DB (więcej instrukcji dostępnych na githubie WP Sync DB):

1. W witrynie na żywo: Skonfiguruj WP Sync DB z włączonym ustawieniem „Zezwalaj na pobieranie z tego repozytorium”.
2. W witrynie tymczasowej: Skonfiguruj WP Sync DB z ustawieniami ściągania z Live. Nazwij to „na żywo do inscenizacji”.
3. W lokalnej konfiguracji deweloperskiej: Skonfiguruj WP Sync DB z ustawieniami ściągania z Live. Nazwij to „na żywo do programisty”.

Możesz również skonfigurować regułę wypychania „od dewelopera do przemieszczania” i sprawdzić ustawienie witryny tymczasowej, aby umożliwić nadpisanie bazy danych.

Zawijanie

Odkryłem, że te metody działają w większości przypadków użycia, zarówno przy tworzeniu nowej witryny WordPress, jak i przy przeprojektowywaniu/refigurowaniu już działającej witryny.

Pozwala na wdrażanie kodu, który utrzymuje aktualność wszystkich wersji witryn bez dodatkowego czasu/wysiłku programistycznego i celowej, bezpiecznej logiki migracji bazy danych w celu pracy między witrynami. Aktualizowanie wtyczek odbywa się również w ramach kontroli źródła, więc aktualizacje wtyczek można bezpiecznie sprawdzać na etapie przemieszczania przed przejściem do działającej witryny, co minimalizuje przerwy w produkcji.

Chociaż z pewnością jest miejsce na ulepszenia, aby wprowadzić więcej przepływu pracy kontroli źródła do zarządzania bazami danych, dopóki narzędzie takie jak VersionPress nie będzie częściej używane w środowiskach produkcyjnych, ta metoda selektywnego ściągania/wypychania bazy danych za pośrednictwem WP Sync DB lub WP Migrate DB Pro wydaje się być najbezpieczniejszą metodą radzenia sobie z tym. Ciekawi Cię, co działa w Twoim przepływie pracy WordPress, lub jeśli po tym wszystkim wolisz po prostu złapać lasso i zakodować go kowbojem!