Чи є 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 - це перша робота з першого виду, але після цього ви можете легко використовувати її для нових налаштувань.

Основні переваги

• можливість розгортання з робочого столу. Це може здатися не дуже схожим, але ssh-ing на віддалений сервер, і робити потяг все ще біль у дупі.
• легкий відкат до попередньої версії, якщо вам потрібно
• вміє робити цікаві речі, такі як розгортання налаштувань у виробничих та виробничих умовах.

Я додаю набір сценаріїв capistrano, щоб показати вам, як я налаштовував речі.

Capfile

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

implemen.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"

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

config / 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 та 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 (Джо Джо Малер; листопад 2008 р.)

Він також окреслений у (якщо вам потрібен другий ресурс, щоб обернути його навколо):

• Використання Git для розгортання (від Dan Barber; квітень 2011)

В основному це працює (щонайменше з трьома репостами):

1. розміщуючи веб-сайт на живому хості під git,
2. створити нове голе сховище git на живому хості.
3. А потім перейдіть від голого сховища до місцевого розвитку git repo (s).

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

Як специфічні параметри Wordpress у репо, у мене є таке .gitignore:

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

Решта в т.ч. плагіни та конфігурації теми я зберігаю під контролем версії / конфігурації. Це дозволяє мені легко відслідковувати зміни та переглядати код, перш ніж використовувати його в прямому ефірі. Я також можу легше злитися проти віддалених дерев із власними змінами. Це особливо корисно проти ядра Wordpress, доступного в Github .

Це працює досить добре для більшості моїх потреб у Wordpress. Оголене репо не дозволяє вам підштовхувати суперечливі зміни. Також він спочатку синхронізується з віддаленою копією перед оновленням живого сайту. Це означає, що оновлення веб-сайту, як правило, відбувається досить швидко. Через гачки ви навіть можете потім зателефонувати на гачки для оновлення Wordpress, якщо хочете.

Якщо ви не експериментували, наскільки це можна вдосконалити за допомогою гачків Github, але мені зазвичай вони не потрібні, оскільки код знаходиться під локальним контролем версій, а не Github.

Щоб вперше налаштувати таку систему, вам знадобиться трохи часу, щоб оцінити, чи є у вас всі інструменти, доступні на віддаленому хості:

• SSH доступ
• GIT
• Приватний каталог, в який можна поміщати файли та підкаталоги (наприклад, для вашого голого git repo)

Час налаштування вперше повинен бути можливим протягом однієї двох годин, в т.ч. все середовище, і ви спочатку публікуєте 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, а також завантаження файлів, базу даних та gpo repo. Також для моїх команд резервного копіювання я можу бути не зовсім гаразд, але вони працюють для мене:

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. Їх потрібно запускати в певній системі, тому їх зазвичай у програмі немає (наприклад, програма може вийти з ладу, але потрібно, щоб вони продовжували працювати).

Увімкнено для роботи в команді

Ще одна приємна перевага полягає в тому, що ваш сайт уже включений для роботи в команді. Завдяки додатковому голому репо ви не можете зробити багато неправильного, і ви навіть можете ділитися віддаленими гілками, крім майстра або живої гілки з колегами.