Является ли Git /GitHub хорошим решением для развертывания WordPress?
В настоящее время я разрабатываю свой WordPress локально, передавая свой код GitHub с Git, а затем SSHing на свой сервер и выполняя «git pull» для обновления моего кода. Является ли это хорошим вариантом для развертывания кода на сайте WordPress (в этом случае я, очевидно, имею доступ к серверу на моем сервере.) Я знаю такие вещи, как Capistrano, но может ли это быть излишним для развертывания на сайте WordPress? Как я могу использовать Git /GitHub в этом случае?
4 ответа
Я использую git для этого и считаю, что он работает очень хорошо. Несколько советов:
- Добавьте каталог каталогов загрузок (wp-content /uploads) в файл
.gitignore
. - Запустите сервер веб-сервера и сервера баз данных в своей системе разработки, чтобы вы могли локально тестировать изменения, прежде чем подталкивать их к производству.
- Содержите настройки подключения к базе данных в dev и prod или добавьте файл wp-config.php в ваш файл
.gitignore
, чтобы предотвратить изменение настроек Wordpress ваших производственных файлов. - Избегайте обновления плагинов на вашей производственной системе, используя интерфейс администратора Wordpress. Как минимум, ваша копия git перезапишет любые плагины, которые вы обновляете, как только вы нажимаете /проверяете, в худшем случае вы столкнетесь с конфликтами. Сделайте свои обновления, используя интерфейс администратора в вашей системе разработки, совершите, нажмите и выйдите в производство.
-
Рассмотрите возможность добавления git
post-receive
для автоматического просмотра ваших обновлений в каталог, который вы используете для публикации wordpress через ваш веб-сервер (например,/var /www
). Это позволяет вам только проверять сами файлы, избегая любых метаданных git, обнаруживающих, что это путь к корню документа вашего веб-сервера, а также означает, что вы можете добавлять любые изменения разрешений в крюк после получения, чтобы ваши разрешения всегда были постоянными. Пример приведен ниже:#! /Bin /ш unset GIT_INDEX_FILE # каталог, на котором ваш веб-сервер обслуживает Wordpress от export GIT_WORK_TREE = /var /www /example.com / # локальный каталог, в котором расположены удаленные сайты репозитория git export GIT_DIR = /home /git /repos /example.com.git / # ниже пользователь отключен - вы хотите, чтобы пользователь и группа, использующая ваш веб-сервер 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 на ваш удаленный сервер, и делать git pull все еще боль в заднице.
- легкий откат к предыдущей версии, если вам нужно
- способен делать классные вещи, такие как развертывание установки в промежуточных /производственных средах.
Я добавляю набор сценариев capistrano, чтобы показать вам, как я настроился.
Capfile
требуется «railsless-deploy»
загрузить 'config /deploy'`
deploy.rb
set: этапы,% w (локализация производства)
set: default_stage, "staging"
требуют «capistrano /ext /multistage»
set: application, "# # ваше имя приложения - используется для установки имени каталога
set: scm,: git
set: repository ", # использовать линию доступа ssh repo, которую вы получаете от поставщика, например [email protected]: 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
пространство имен: задачи
задача: fix_links do
запустите «ln -nfs # {shared_path} /uploads # {release_path} /wp-content /uploads"
запустите «ln -nfs # {shared_path} /wp-config.php # {release_path} /wp-config.php"
запустите «ln -nfs # {shared_path} /blogs.dir # {release_path} /wp-content/blogs.dir"
запустить "ln -nfs # {shared_path} /. htaccess # {release_path} /. htaccess"
run "sudo chown -R www-data.www-data # {release_path} /"
конец
конец
после «развертывания», «задачи: fix_links»
и, наконец, пример файла окружения (если вы используете многоступенчатый камень, то вы можете иметь один из них для каждого этапа вашей среды, например, локальный, этап, производство)
конфигурации /local.rb
server "",: app #hostname
set: branch, 'develop' # выбрать ветку для развертывания
set: use_sudo, false # не использовать sudo
set: deploy_to, "/var /www /# {application}" #overwrite путь по умолчанию для развертывания
Эти файлы могут не работать без настройки, и вам понадобятся некоторые основные знания Capistrano, но, надеюсь, это поможет некоторым людям.
Это был первый учебник, который я использовал, который заставил меня пойти с Capistrano и WordPress: http://theme.fm/2011/08/tutorial-deploying-wordpress-with-capistrano-2082/
Я действительно сделал презентацию WordCamp по этой теме. Вместо повторения, вот скринкаст этого и вот очень простой сценарий развертывания , чтобы сопровождать то, что я обсуждал.
Короче говоря, я использую GitHub для размещения репо и использую webhook для развертывания изменений на основе git ref. Это позволяет использовать модель ветвления Git Vincent Driessen и открывает вам неограниченные веб-сайты, промежуточных серверов, серверов тестирования и т. д., все с автоматическим развертыванием. Я также рассказываю о сохранении wp-config.php под управлением версии, поддерживая отдельные версии dev /production (путем переименования файлов и символических ссылок).
Я знаю, что этот вопрос немного старше, однако, поскольку я не видел этого в качестве ответа здесь, я хотел бы поделиться тем, что я обычно делаю для однозадачных git-установок и развертываний, и он работает очень хорошо, также с работая из нескольких устройств, местоположений и с несколькими разработчиками (все из которых имеют свои собственные локальные репозитории, в которых они работают, поскольку они распространены для git).
Я могу сердечно предложить следующую настройку:
Также указывается (если вам нужен второй ресурс, чтобы обернуть вокруг него голову):
В основном он работает (по крайней мере с тремя репозиториями):
- размещение веб-сайта на live-host под git,
- создайте новый готический репозиторий git на живом хосте.
- И затем вилка из голого репозитория в вашу локальную разработку git repo (s).
Когда работа завершена, вы нажимаете на удаленный пустой репо, из которого вы клонировали. У голого репо есть крючки для синхронизации с live-репо (в приведенных выше кодах prime ).
Как специальные параметры Wordpress в репо, у меня есть этот .gitignore
:
# uploads - данные, исключенные из исходного дерева
WP-содержание /добавления /
Остальные вкл. настройки плагина и темы, которые я поддерживаю под управлением версии /конфигурации. Это позволяет мне легко отслеживать изменения и просматривать код до , используя его вживую. Я также могу более легко сливаться с удаленными деревьями с моими собственными изменениями. Это особенно полезно для ядра Wordpress, доступного в Github .
Это работает очень хорошо для большинства моих потребностей Wordpress. Голый репо не позволяет вам выдвигать противоречивые изменения. Он также синхронизируется с удаленной копией сначала перед обновлением сайта. Это означает, что обновление живого сайта обычно довольно быстро. Из-за перехватов вы можете даже вызвать перехватывание Wordpress после этого, если хотите.
Если вы не экспериментировали, насколько это можно улучшить с помощью Github-перехватчиков, но я обычно не нуждаюсь в них, поскольку код находится под контролем локальной версии, а не с Github.
Чтобы установить такую систему в первый раз, вы должны потратить некоторое время, чтобы оценить, есть ли у вас все инструменты на удаленном хосте:
- Доступ к SSH
- ГИТ
- Частный каталог, в который вы можете поместить файлы и подкаталоги (например, для вашего голого репозитория git)
Время установки в первый раз должно быть возможно в течение двух часов, включая. всю среду, и вы сначала публикуете push.
В зависимости от вашего хоста вы также можете защитить каталог .git
от веб-доступа. Вот пример кода .htaccess
, который даже делает это, если Wordpress помещен внутри подкаталога, что оставляет пространство в репо, которое не публикуется в Интернете (полезно):
Опции -Indexes
# Исправить завершающий слэш для .git /заставить его исчезнуть + .gitignore и подобные файлы.
RedirectMatch 404 ^ /\. Git (. *) $
# маска 403 на .ht * как 404
<Файлы ~ "^ \. ht">
Отменить заказ, разрешить
Разрешить от всех
Удовлетворить всех
Переадресация 404 /
& Lt; /& Файлы GT;
RewriteEngine On
RewriteBase /
# отобразить все в общедоступную и установить среду var
#, чтобы пометить, что запрос действителен
RewriteCond% {ENV: REDIRECT_sitealias}!
RewriteRule ^ (. *) $ /Public /$ 1 [E = sitealias: set, L]
Короче говоря, все, что находится внутри общедоступного , не находится в сети. Внутри каталога public может быть, например, wordpress codebase, для .htaccess
вам нужно:
RewriteEngine On
# mask как 404 при прямом доступе
RewriteCond% {ENV: REDIRECT_sitealias}!
RewriteRule. * - [L, R = 404]
Это предотвращает прямой доступ к public . Часть этого .htaccess -foo вы можете найти здесь: Запросы .htaccess должны возвращать 404 вместо 403 . Для переменных среды вам нужно проверить, работает ли это в вашей среде. Также вам нужно решить, помещаете ли вы это под контроль версий или нет.
Если у вас больше возможностей для управления хостингом, вы можете сделать больше здесь (и по-разному /оптимизированнее), приведенные выше примеры ориентированы на типичные среды с общим хостингом (которые предлагают GIT, некоторые пользователи говорят, что вы можете легко установить его ваш собственный, я обычно прошу своих хостеров предоставить такие, потому что я предпочитаю, если они позаботятся, это то, за что я их плачу.).
С отрицательной стороны, это имеет некоторые общие проблемы, также изложенные в других ответах. Одна вещь, которую я не горжусь, но то, что работает, - это датьхост разработки изменит его файл хоста, чтобы сервер базы данных указал на копию разработки. Таким образом, вы можете сохранить одну конфигурацию базы данных. Не очень классно esp. из-за учетных данных.
Автоматическое резервное копирование
Однако мне, как правило, все равно, но вместо этого ежедневные резервные копии запускаются на удаленных системах, которые постепенно увеличиваются, которые сами хранятся в другом удаленном месте. Это легко и недорого и позволяет восстанавливать как Wordpress-установку, так и файлы-загрузки, базу данных и git repo. Также для моих команд резервного копирования я, возможно, не совсем в порядке, но они работают для меня:
mysql: mysqldump --host =% s -u% s --password =% s% s | gzip> % s
git: git gc
git bundle
файлов: tar --force-local -czf% s% s
Что я предлагаю здесь, так это то, что вы держите процессы в своей установке Wordpress вне Wordpress. Они должны запускаться в определенной системе, поэтому вы обычно не используете их внутри приложения (например, приложение может опускаться, но вы нуждаетесь , чтобы они продолжали работать).
Включено для совместной работы
Еще одно приятное преимущество в том, что ваш сайт уже включен для командной работы. Благодаря дополнительному годовому репо вы не можете ошибиться, и вы даже можете делиться удаленными ветвями отдельно от ведущего или живого филиала с вашими коллегами.