Непрерывное развертывание WordPress и контроль версий с помощью Bitbucket

Хорошо, ребята. Время признаться.

Если вы в чем-то похожи на меня, то первые годы разработки WordPress вы потратили на «ковбойское кодирование», то есть на то, чтобы вносить дикие изменения на работающие сайты, срочно тестировать и запускать их с помощью FTP, что часто приводит к 500 сообщениям об ошибках внутреннего сервера и sitewide ломает все видимое вашим уважаемым посетителям.

Хотя это было абсолютно захватывающе, когда адреналин качал сквозь ваши пальцы, отбивая эту забытую точку с запятой, на сайтах с более чем 0 посетителями (которые действительно заметили время простоя) это начинало становиться проблемой. Если дерево падает, и никто не слышит его, издает ли оно звук? Зависит от теории человечества, которой вы придерживаетесь.

Однако, если сайт выйдет из строя и кто-то его увидит, он обязательно поднимет шум.

Непрерывное развертывание WordPress сделано неправильно

Введите промежуточные сайты, продублируйте установки WordPress (по крайней мере, теоретически), где можно было бы внести изменения, а затем снова сделайте это на рабочем сайте, как только все будет подтверждено. Хотя это успокоило посетителей, мы, разработчики, начали поднимать шум. Внезапно нам понадобилось отслеживать два сайта, убедиться, что код синхронизируется между ними вручную, и снова все протестировать, чтобы убедиться, что он работает на действующем сайте. Длинные, запутанные списки «не забудьте изменить это в реальном времени» и «не забудьте переключить это на промежуточном сайте, прежде чем копировать код» были, мягко говоря, нервными. Резервные копии этой системы тоже были кошмаром — множество папок с именами «my-theme-staging-1», «my-theme-live-before-menu-restyle-3» и так далее.

Должен был быть лучший способ, и он был.

Был Git, который дает разработчикам идеальный контроль версий и другие возможности. Использование контроля версий для установок WordPress мгновенно ускорило и очистило разработку, так как часы больше не тратились на резервное копирование в системе для каждого разработчика, а фактически на кодирование. Изменения были сохранены, и я, наконец, смог добавить в свою работу значимые сообщения, миры отличий от «моя-тема-4-v2».

Хотя кодовая база была намного чище, проблема по-прежнему оставалась в фактическом развертывании и обеспечении того, чтобы рассматриваемый сайт использовал последний код — введите возможность для человеческой ошибки. Все еще полагаться на ручную загрузку FTP, перезаписывая предыдущий код, было не очень приятно. В то время как существовали другие сервисы CI/CD, многие из них имели существенную цену и большой объем настройки — перенастройка сервера, использование еще одного сервиса даже для самого простого веб-сайта, изучение всего «способа ведения дел» другого сервиса и все остальное. идиосинкразии, которые приходят с ним.

Хотя настройки, подобные этому руководству, можно выполнить с помощью GitHub/GitLab и других сервисов, я заранее положил свои яйца в корзину Atlassian из-за их бесплатных частных репозиториев (которые были недавно предложены GitHub). Когда Bitbucket представила свои службы Pipelines и Deployments , это позволило автоматически развертывать новый код на промежуточных или рабочих сайтах (или на любом другом промежуточном сайте) без повторной загрузки через FTP или использования внешней службы. Разработчики теперь могут использовать все значения системы управления версиями в своей разработке WordPress и мгновенно отправлять эти изменения в соответствующие места назначения без дополнительных кликов или нажатий клавиш, со статусом всего, видимым на одной панели. Это гарантирует, что все будет синхронизировано, и с первого взгляда позволит вам точно узнать, какой код работает на каждом сайте. Кроме того, цены на минуты сборки Bitbucket невероятно доступны: 50 бесплатных минут в месяц и возможность выбрать план «Бесплатно с излишками».

Потребовалось немного времени для запуска, чтобы выяснить, как лучше всего использовать ветки и другие функции системы управления версиями в этой новой модели, а также особенности настройки Bitbucket Pipelines. Вот процесс, который я использую для запуска новых проектов WordPress. Я не буду вдаваться во все тонкости настройки git и установки WordPress, так как отличные ресурсы для этого находятся на расстоянии поиска в Google. В итоге поток контента будет примерно таким:

Процедура депонирования Alexa Green WordPress

Шаги, описанные здесь, следует выполнять по мере необходимости:

На клиентском сервере

Настройте домен для работающего сайта (например, clientsite.com) и субдомен для промежуточного размещения (например, staging.clientsite.com).

Установите WordPress как на работающий сайт, так и на промежуточный поддомен. Это можно сделать через cPanel/Softaculous (если это есть на хостинге клиента) или скачав с wordpress.org. Убедитесь, что существуют отдельные базы данных для live и staging соответственно.

На Bitbucket.com

Настройте новый репозиторий. Включите .README, чтобы мы могли начать работу.

В репозитории Settings > Pipelines > Settings затем установите флажок Enable Pipelines .

В Настройки > Конвейеры > Переменные репозитория введите следующее:

 Name: FTP_username Value: The client FTP username

 Name: FTP_password Value: The client FTP password 

Вернитесь в Pipelines > Settings и нажмите кнопку Configure bitbucket-pipelines.yml . Выберите PHP в качестве языка на следующей странице. Вы захотите использовать что-то вроде следующего кода. Обязательно замените версию PHP на то, что вы используете на клиентском сервере, а URL-адреса/FTP-серверы — на фактические URL-адреса/FTP-серверы клиентского сайта (рабочие и промежуточные).

 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 

Щелкните Зафиксировать файл . Теперь установка Pipelines будет зафиксирована и запущена.

Если все развертывается успешно, вернитесь и отредактируйте файл bitbucket-pipelines.yml (вы можете попасть туда через Pipelines > Settings и View bitbucket-pipelines.yml ). Вы захотите заменить оба места, где написано git ftp init , на git ftp push and save/commit. Это обеспечит загрузку только измененных файлов, что сэкономит вам минуты сборки. Теперь ваш файл bitbucket-pipelines.yml должен выглядеть так:

 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 

Добавьте ветку с именем main-dev .

На вашей локальной машине

Клонируйте репозиторий в пустой каталог, который вы хотите использовать для локальной установки. Проверьте ветку main-dev .

Настройте локальную установку WP в этом каталоге. Для этого существует множество инструментов — Local by Flywheel, MAMP, Docker и т. д. Убедитесь, что все совпадает (версия WordPress, версия PHP, Apache/Nginx и т. д.) с тем, что работает на клиентском сервере.

Добавьте .gitignore , который выглядит примерно так. По сути, мы хотим, чтобы Git игнорировал все, кроме wp-content (чтобы предотвратить проблемы с установкой между установками). Вы также можете добавить свои собственные правила игнорирования больших файлов резервных копий и созданных системой значков и файлов 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

Сохраните и зафиксируйте .gitignore .

Внесите изменения и зафиксируйте их соответствующим образом.

Каждый раз, когда вы совершаете коммит в main-dev, он запускает FTP-загрузку на промежуточный сайт. Каждый раз, когда вы фиксируете мастер, он запускает FTP-загрузку на рабочий сайт. Обратите внимание, что на это уйдут минуты на сборку, поэтому вы можете сделать большинство локальных изменений в ответвлении от main-dev, а затем объединиться с main-dev, как только вы закончите в течение дня.

Слияние main-dev с master внесет в жизнь все промежуточные изменения. Вы можете проверить статус конвейеров и развертываний в репозитории на Bitbucket.org.

Синхронизация баз данных WordPress между установками

Обратите внимание, что вышеперечисленное будет синхронизировать только файлы (темы, плагины и т. д.). Синхронизация базы данных между производственной и промежуточной версиями становится другим вопросом, поскольку часто клиенты вносят изменения на работающем сайте, которые не отражаются на промежуточном сайте, и наоборот.

Для синхронизации баз данных между установками WordPress существует несколько вариантов. Традиционно вы можете обновлять базы данных, импортируя/экспортируя их через phpmyadmin . Однако это сложно, так как он не может обновлять определенные вещи, которые необходимо обновить, например, постоянные ссылки в контенте публикации. При использовании этого метода любимым инструментом является плагин Velvet Blues Update URLs, который затем можно использовать для поиска/замены любых экземпляров старого URL-адреса сайта (например, https://staging.clientsite.com) на новый URL-адрес сайта ( например, https://clientsite.com). Вы также можете использовать это с относительными путями и строками. Этот метод в конечном итоге оставляет много места для человеческой ошибки — если замененная строка написана неправильно, это может привести к поломке всего сайта и невозможности использовать плагин / получить доступ к панели инструментов.

В то время как плагин, такой как All-in-One WP Migration, предлагает функцию поиска/замены из коробки и невероятно удобен для пользователя, он также переносит файлы, тем самым отменяя значения всего нашего рабочего процесса Pipelines. Кроме того, поскольку он повторно импортирует все wp-загрузки, это может привести к огромным файлам и времени загрузки (поэтому он не подходит для переноса изменений между установками). Подобный плагин лучше всего использовать для резервного копирования всего сайта в целях архивации/безопасности.

VersionPress кажется интересным решением, но оно еще не проверено во многих производственных средах. На данный момент такие плагины, как WP Sync DB или WP Migrate DB Pro, кажутся лучшими решениями для управления базами данных. Они позволяют извлекать/передавать базы данных между установками, предоставляя возможность автоматического обновления URL-адресов и путей. Они могут мигрировать только определенные таблицы, например wp_posts только для контента поста, не тратя время на повторный импорт пользователей и настроек всего сайта. Мне нравится всегда извлекать данные из live, чтобы убедиться, что никакие производственные данные не будут перезаписаны. Вот пример настройки, если вы используете WP Sync DB (дополнительные пошаговые руководства доступны на github WP Sync DB):

1. На действующем сайте: настройте WP Sync DB с включенным параметром «Разрешить извлечение из этого репозитория».
2. На тестовом сайте: настройте WP Sync DB с настройками Pull from Live. Назовите это «прямой эфир».
3. В вашей локальной настройке разработчика: настройте WP Sync DB с настройками Pull from Live. Назовите это «жить для разработки».

Вы также можете настроить правило отправки «dev-to-staging» и проверить настройку промежуточного сайта, чтобы разрешить перезапись базы данных.

Подведение итогов

Я обнаружил, что эти методы, как правило, работают в большинстве случаев, как при разработке нового веб-сайта WordPress, так и при редизайне/реконфигурации уже работающего сайта.

Это позволяет развертывать код, который поддерживает все версии сайта в актуальном состоянии без дополнительного времени и усилий разработчиков и преднамеренной безопасной логики миграции базы данных для работы между сайтами. Обновление плагинов также выполняется в системе управления версиями, поэтому обновления плагинов можно безопасно проверять на стадии подготовки перед фиксацией на рабочем сайте, что сводит к минимуму перерывы в работе сайта.

Хотя, безусловно, есть возможности для улучшения, чтобы привнести больше рабочего процесса управления исходным кодом в управление базой данных, до тех пор, пока такой инструмент, как VersionPress, не будет больше использоваться в производственных средах, этот метод выборочного извлечения / отправки базы данных через WP Sync DB или WP Migrate DB Pro кажется чтобы быть самым безопасным методом борьбы с этим. Любопытно услышать, что работает для вашего рабочего процесса WordPress, или если после всего этого вы бы предпочли просто взять свое лассо и ковбойский код!