Git/GitHub как решение для развертывания WordPress

Я настоятельно рекомендую настроить Capistrano — это требует немного подготовительной работы в первый раз, но затем вы сможете легко использовать его для новых проектов.

Основные преимущества:

• Возможность развертывания прямо с рабочего компьютера. Может показаться незначительным, но подключение по SSH к удаленному серверу и выполнение git pull всё равно остаётся головной болью.
• Простой откат к предыдущей версии, если это потребуется
• Возможность делать крутые вещи, например, настраивать развертывание для staging/production окружений.

Я добавлю набор скриптов Capistrano, чтобы показать, как я это настраиваю.

Capfile

require 'railsless-deploy'
load 'config/deploy'`

deploy.rb

set :stages, %w(production staging local)
set :default_stage, "staging"
require 'capistrano/ext/multistage'

set :application, "" # название вашего приложения — используется для создания имени директории

set :scm, :git
set :repository, "" # используйте SSH-адрес репозитория от провайдера, например git@github.com:name/repo.git
set :deploy_to, "/var/www/#{application}" # это корневая папка сайта на удалённом сервере
set :deploy_via, :remote_cache # получать напрямую из репозитория
set :copy_exclude, [".git", ".DS_Store", ".gitignore", ".gitmodules", "wp-config.php"]

# заставляет Capistrano запрашивать пароль sudo или другие данные для удалённого сервера
default_run_options[:pty] = true

namespace :tasks do
    task :fix_links  do
        run "ln -nfs #{shared_path}/uploads #{release_path}/wp-content/uploads"
        run "ln -nfs #{shared_path}/wp-config.php #{release_path}/wp-config.php"
      run "ln -nfs #{shared_path}/blogs.dir #{release_path}/wp-content/blogs.dir"
      run "ln -nfs #{shared_path}/.htaccess #{release_path}/.htaccess"
      run "sudo chown -R www-data.www-data #{release_path}/"
    end
end

after "deploy", "tasks:fix_links"

И, наконец, пример файла окружения (если вы используете multistage, то у вас может быть отдельный файл для каждого окружения: local, staging, production).

config/local.rb

server "", :app  #имя хоста
set :branch, 'develop' #выберите ветку для развертывания
set :use_sudo, false #не использовать sudo

set :deploy_to, "/var/www/#{application}" #переопределить путь по умолчанию для развертывания

Эти файлы могут потребовать доработки, и вам понадобятся базовые знания Capistrano, но, надеюсь, они помогут некоторым людям.

Вот первый туториал, который помог мне начать работать с Capistrano и WordPress: http://theme.fm/2011/08/tutorial-deploying-wordpress-with-capistrano-2082/

Я действительно делал презентацию на WordCamp по этой теме. Вместо того, чтобы повторяться, вот скринкаст этой презентации и вот очень простой скрипт для деплоя, который дополняет то, что я обсуждал.

Коротко говоря, я использую GitHub для хранения репозитория и вебхук для деплоя изменений на основе git ref. Это позволяет использовать модель ветвления git Винсента Дриссена и открывает возможности для неограниченного количества веб-серверов, staging-серверов, тестовых серверов и т.д. с автоматизированным деплоем. Я также рассказываю о том, как держать wp-config.php под контролем версий, сохраняя при этом отдельные версии для разработки и продакшена (через переименование файлов и симлинки).

Я знаю, что этот вопрос довольно старый, но так как я не видел такого ответа здесь, хочу поделиться своим подходом к git-настройкам и деплою для однопользовательских сайтов, который отлично работает, в том числе при работе с нескольких устройств, из разных локаций и с несколькими разработчиками (у каждого есть свои локальные репозитории, как это принято в git).

Могу горячо рекомендовать следующую настройку:

• Веб-ориентированный Git-воркфлоу (Joe Maller; ноябрь 2008)

Также это описано здесь (если вам нужен дополнительный источник для понимания):

• Использование Git для деплоя (Dan Barber; апрель 2011)

Вкратце система работает (с минимум тремя репозиториями) следующим образом:

1. Размещаем сайт на продакшн-хостинге под управлением git,
2. Создаем новый bare git-репозиторий на продакшн-хостинге.
3. Форкаем из bare-репозитория в локальный git-репозиторий для разработки.

После завершения работы вы пушите изменения в удаленный bare-репозиторий, откуда клонировали. Bare-репозиторий имеет хуки для синхронизации с рабочим репозиторием (в приведенных выше примерах он называется prime).

Для WordPress у меня в репозитории есть такой .gitignore:

# папка uploads содержит данные, исключаем из исходников
wp-content/uploads/

Все остальное, включая настройки плагинов и тем, я держу под контролем версий. Это позволяет легко отслеживать изменения и проверять код перед выкладкой на продакшен. Также упрощается слияние с удаленными репозиториями, например, с ядром WordPress на Github.

Такая схема отлично работает для большинства моих WordPress-проектов. Bare-репозиторий предотвращает конфликты при пуше изменений. Синхронизация с продакшеном происходит быстро благодаря хукам. При желании можно даже вызывать WordPress-хуки после обновления.

Я не экспериментировал с Github-хуками для улучшения процесса, так как код находится под локальным контролем версий, а не на Github.

Для первоначальной настройки системы потребуется оценить наличие необходимых инструментов на хостинге:

• SSH-доступ
• GIT
• Приватная директория для bare git-репозитория

Первоначальная настройка занимает 1-2 часа, включая развертывание окружения и первый деплой.

На некоторых хостингах может потребоваться закрыть доступ к директории .git через веб. Пример правил для .htaccess (работает даже если WordPress установлен в поддиректорию):

Options -Indexes

# редирект для .git и подобных файлов
RedirectMatch 404 ^/\.git(.*)$

# маскируем 403 ошибку для .ht* как 404
<Files ~ "^\.ht">
  Order Deny,Allow
  Allow from all
  Satisfy All
  Redirect 404 /
</Files>

RewriteEngine On
RewriteBase /

# перенаправляем все в public и устанавливаем переменную окружения
RewriteCond %{ENV:REDIRECT_sitealias} !set
RewriteRule ^(.*)$ /public/$1 [E=sitealias:set,L]

Коротко: все что вне директории public недоступно из веба. В public может находиться WordPress. Для его .htaccess:

RewriteEngine On
# маскируем прямой доступ как 404
RewriteCond %{ENV:REDIRECT_sitealias} !set
RewriteRule .* - [L,R=404]

Это предотвращает прямой доступ к public. Часть этого подхода описана здесь: Requests to .htaccess should return 404 instead of 403. Работу переменных окружения нужно проверять индивидуально. Также решите, добавлять ли эти файлы в репозиторий.

На более управляемых хостингах можно реализовать более оптимальные решения. Приведенные примеры ориентированы на shared-хостинги с поддержкой GIT.

Из минусов - некоторые общие проблемы, описанные в других ответах. Например, не самое элегантное решение - правка hosts-файла на разработческой машине для перенаправления запросов к БД на тестовую копию. Это небезопасно из-за хранения учетных данных.

Автоматические бэкапы

Я не заморачиваюсь с этим, так как на удаленных серверах настроены ежедневные инкрементальные бэкапы, которые хранятся в другом месте. Это позволяет восстанавливать и WordPress, и загруженные файлы, и БД, и git-репозиторий. Мои команды для бэкапов:

mysql: mysqldump --host=%s -u %s --password=%s %s| gzip > %s
git  : git gc
       git bundle
files: tar --force-local -czf %s %s

Рекомендую выносить процессы, связанные с WordPress, за его пределы. Приложение может упасть, но эти процессы должны продолжать работать.

Командная работа

Дополнительный плюс - сайт сразу готов для командной работы. Благодаря bare-репозиторию сложно что-то сломать, а коллеги могут использовать отдельные ветки помимо master/live.