Является ли Git/GitHub хорошим решением для развертывания WordPress?

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

Основными преимуществами являются

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

Я добавляю набор сценариев capistrano, чтобы показать вам, как я все настраиваю.

Файл Capfile

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

Развернуть.rb

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

set :application, "" # your application name - used to set directory name

set :scm, :git
set :repository, "" # use the ssh repo access line you get from the provider eg [email protected]:name/repo.git
set :deploy_to, "/var/www/#{application}" #this is the root site folder on the remote server
set :deploy_via, :remote_cache # get directly from repo
set :copy_exclude, [".git", ".DS_Store", ".gitignore", ".gitmodules", "wp-config.php"]

# makes capistrano ask for sudo password or other remote inputs
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"

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

Конфигурация/локальный.rb

server "", :app  #hostname
set :branch, 'develop' #choose branch to deploy
set :use_sudo, false #don't use sudo

set :deploy_to, "/var/www/#{application}" #overwrite default path to deploy to

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

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

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

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

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

Я могу от всего сердца предложить следующую настройку:

• Веб-ориентированный рабочий процесс Git (от Джо Маллер; Ноябрь 2008)

Это также описано в (если вам нужен второй ресурс, чтобы понять это):

• Использование Git для развертывания (автор Дэн Барбер; апрель 2011)

В основном это работает (по крайней мере, с тремя репозиториями) с помощью:

1. размещение веб-сайта на живом хостинге под git,
2. создайте новый голый репозиторий git на живом хосте.
3. , А затем разветвляйте из голого репозитория на свой локальный репо(ы) git для разработки.

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

В качестве специфических настроек Wordpress в репозитории у меня есть это .gitignore:

# uploads are data, excluded from source tree
wp-content/uploads/

Остальное, включая конфигурацию плагина и темы я держу под контролем версии/конфигурации. Это позволяет мне легко отслеживать изменения и просматривать код , прежде чем использовать его в реальном времени. Я также могу легче объединяться с удаленными деревьями с моими собственными изменениями. Это особенно полезно против ядра Wordpress , которое доступно на Github.

Это довольно хорошо работает для большинства моих потребностей в Wordpress. Простое репо не позволяет вам вносить конфликтующие изменения. Он также сначала синхронизируется с удаленной копией, прежде чем обновлять живой сайт. Это означает, что обновление живого сайта обычно происходит довольно быстро. Из-за крючков вы даже можете впоследствии вызвать крючки обновления Wordpress, если вам нравится.

Если вы не экспериментировали, насколько это можно улучшить с помощью крючков Github, но обычно они мне не нужны, так как код находится под локальным контролем версий, а не на Github.

Чтобы настроить такую систему в первый раз, вам следует потратить некоторое время, чтобы оценить, есть ли у вас все инструменты, доступные на вашем удаленном хосте:

• Доступ по SSH
• МЕРЗАВЕЦ
• Частный каталог, в который вы можете поместить файлы и подкаталоги (например, для вашего голого git репо)

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

В зависимости от вашего хоста, вы также можете захотеть защитить каталог .git от веб-доступа. Вот пример .htaccess кода, который даже делает это, помещая Wordpress в подкаталог, что оставляет место в репозитории, не опубликованном в Интернете (полезно):

Options -Indexes

# fix trailing slash for .git / make it disappear + .gitignore and similar files.
RedirectMatch 404 ^/\.git(.*)$

# mask 403 on .ht* as 404
<Files ~ "^\.ht">
  Order Deny,Allow
  Allow from all
  Satisfy All
  Redirect 404 /
</Files>

RewriteEngine On
RewriteBase /

# map everything into public and set environment var
# to tag the request being valid
RewriteCond %{ENV:REDIRECT_sitealias} !set
RewriteRule ^(.*)$ /public/$1 [E=sitealias:set,L]

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

RewriteEngine On
# mask as 404 if directly accessed
RewriteCond %{ENV:REDIRECT_sitealias} !set
RewriteRule .* - [L,R=404]

Это предотвращает прямой доступ к общедоступным . Часть этого .htaccess-foo вы можете найти здесь: Запросы к .htaccess должны возвращать 404 вместо 403. Для переменных среды вам нужно проверить, работает ли это в вашей среде. Также вам нужно решить, ставите ли вы это под контроль версий или нет.

Если у вас больше контроля над хостингом, вы можете сделать здесь больше (и по-другому/более оптимизировано), приведенные выше примеры предназначены для типичных сред общего хостинга (которые предлагают GIT, некоторые пользователи говорят, что вы также можете легко установить его самостоятельно, я обычно прошу своих хостеров предоставить такие, потому что я предпочитаю, чтобы они заботились о том, за что я им плачу).

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

Автоматическое резервное копирование

Однако обычно мне здесь все равно, но вместо этого на удаленных системах ежедневно выполняются резервные копии, которые постепенно сохраняются в другом удаленном месте. Это легко и дешево и позволяет вы должны восстановить как установку 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, вне Wordpress. Они должны запускаться в определенной системе, поэтому обычно у вас их нет внутри приложения (например, приложение может отключиться, но вам нужно, чтобы они продолжались на работу).

Включено для совместной работы

Еще одно приятное преимущество заключается в том, что ваш сайт уже включен для командной работы. Благодаря дополнительному голому репо вы не можете сделать много плохого, и вы даже можете делиться удаленными ветвями, кроме главной или живой ветви, со своими коллегами.