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

В настоящее время я разрабатываю свой WordPress локально, фиксирую свой код в GitHub с помощью Git, а затем SSHing на моем сервере и выполняю «git pull» для обновления моего кода. Является ли это хорошим вариантом для развертывания кода на сайте WordPress (в этом случае у меня, очевидно, есть доступ к моему серверу с правами суперпользователя). Я знаю такие вещи, как Capistrano, но будет ли это излишним для развертывания на сайте WordPress? Как я могу максимально использовать Git / GitHub в этом случае?

Я использую Git для этого и считаю, что он работает очень хорошо. Несколько предложений:

• Добавьте ваш каталог загрузки (wp-content / uploads) в ваш .gitignoreфайл.
• Запустите веб-сервер и сервер базы данных в своей системе разработки, чтобы вы могли проверить изменения локально, прежде чем отправлять их в производство.
• Сохраняйте параметры подключения к базе данных между dev и prod или добавьте wp-config.php в свой .gitignoreфайл, чтобы настройки WordPress для разработки не перезаписывали ваши рабочие.
• Избегайте обновления плагинов в вашей производственной системе с помощью интерфейса администратора Wordpress - в лучшем случае ваша git-копия будет перезаписывать все плагины, которые вы обновляете, как только вы нажимаете / извлекаете, в худшем случае вы получите конфликты. Выполняйте обновления, используя интерфейс администратора в вашей системе разработки, фиксируйте, отправляйте и извлекайте в процессе производства.

• Подумайте о добавлении Git- post-receiveхука, чтобы автоматически получать обновления в каталоге, который вы используете для публикации WordPress через ваш веб-сервер (например /var/www). Это позволяет вам проверять только сами файлы, избегая любых метаданных git, попадающих в корневой каталог документа вашего веб-сервера, а также означает, что вы можете добавлять любые изменения разрешений в ловушку пост-получения, чтобы ваши разрешения всегда оставались согласованными. Пример приведен ниже:

  #!/bin/sh
  unset GIT_INDEX_FILE
  # the directory your web server serves wordpress from 
  export GIT_WORK_TREE=/var/www/example.com/
  # the local directory where your remote git repository sites
  export GIT_DIR=/home/git/repos/example.com.git/
  # below user is for debain - you want the user and group your webserver uses
  sudo git checkout -f
  sudo chown -R www-data:www-data $GIT_WORK_TREE
  sudo chmod -R 755 $GIT_WORK_TREE
  sudo chmod 600 $GIT_WORK_TREE/wp-config.php
  sudo chmod -R 775 $GIT_WORK_TREE/wp-content

Я очень рекомендую настроить 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, "" # 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 git@github.com: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"

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

конфиг / local.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, но, надеюсь, это поможет некоторым людям.

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

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

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

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

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

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

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

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

В основном это работает (по крайней мере с тремя репо):

1. положить сайт на live-host под git,
2. создайте новый репозиторий git на живом хосте.
3. А затем переходите от простого репозитория к вашему локальному git-репозиторию разработки.

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

В качестве конкретных настроек WordPress в репо у меня это .gitignore:

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

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

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

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

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

• Доступ по SSH
• GIT
• Личный каталог, в который вы можете помещать файлы и подкаталоги (например, для вашего простого 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, некоторые пользователи говорят, что вы можете легко установить его самостоятельно, как ну, я обычно прошу своих хостеров предоставить такие, потому что я предпочитаю, чтобы они позаботились о том, за что я им заплачу).

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

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

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

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

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