Схема веб-разработки для промежуточных и производственных серверов с использованием Git Push

Question

Я использую git для управления динамическим веб-сайтом (PHP + MySQL) и хочу отправить свои файлы с моего localhost на мои staging и development серверы наиболее эффективным и простым способом.

В настоящее время я убежден, что лучший способ для меня решить эту проблему - использовать эту модель ветвления git для организации моего локального репозитория git,Оттуда я буду использовать ветки release для push на моем промежуточном сервере для тестирования.Если я счастлив, что код release работает на промежуточном сервере , я могу merge с моей master веткой и push с моей рабочий сервер .

Переход на промежуточный сервер :

Как отмечалось во многих вступительных постах git s, я мог столкнуться спроблемы push в non-bare репо, поэтому, как предлагается в этом ответе , я планирую push выпустить ветку с bare репо на сервереи иметь перехват после получения, который clone s * репозиторий bare для репо non-bare, который также выступает в качестве веб-каталога.

Пересылка на Рабочий сервер :

Вот мой новый источник путаницы ...

В ответе, который я цитировал выше, мне стало любопытно, почему @Paul утверждает, что это совершенно другая история, когда push ing сервер разработки .Я думаю, я не вижу проблемы.Было бы безопасно и без проблем выполнить те же действия, что и выше, но для ветви master ?Где потенциальные ошибки?

Файлы конфигурации:

Что касается файлов конфигурации, уникальных для каждой среды (.htaccess, config.php и т. Д.), Кажется, что проще всего.gitignore каждый из этих файлов в соответствующих репозиториях на своих серверах.Можете ли вы увидеть что-то сразу не так с этим?Лучшие решения?

Доступ к данным:

Наконец, как я уже говорил, сайт использует базы данных MySQL для хранения данных.Как бы вы предложили мне получить доступ к этим данным (для целей тестирования) с промежуточного сервера и localhost ?

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

Answer 1

Отправка на производственный сервер

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

Я думаю, что подход, к которому вы обращаетесь (развертывание путем отправки в пустой репозиторий с post-receive, который делает git checkout -f с соответствующим значением GIT_WORK_TREE), является хорошим подходом для развертывания из git.

Файлы конфигурации

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

• Как я могу иметь разные версии файла в локальном рабочем каталоге, удаленном рабочем каталоге и цели git ftp?

Доступ к данным

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

Answer 2

Я тоже использую git flow. Для файлов конфигурации в expressionengine мы используем ee master config , который в основном определяет среду, в которой он находится, и применяет конкретную конфигурацию. Я полагаю, что это можно легко изменить для всего, что вы делаете.

Для развертываний мы используем Beanstalk , который позволяет добавить «[deploy: Environment]» к сообщению о коммите, что заставит его загрузить (ftp) указанную вами ветку (ту, которую вы коммитите) к указанной среде, которую вы настраиваете в их веб-интерфейсе, когда выполняете команду git push.

Я пытался найти эффективное решение для файлов .htaccess, которое позволило бы мне htpasswd в одной из моих сред, но не во всех. Похоже, это возможно в Apache 2.3 с чем-то вроде этого:

<if "%{HTTP_HOST} == 'dev.example.com'">
    # auth directives
</if>

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

Answer 3

FAQ Git рекомендует этот скрипт перехвата пост-получения для сброса заголовка не-пустого хранилища после его отправки в.Это сохранит любые изменения, которые не были переданы на пульт, используя тайник.Лично я предпочел бы, чтобы в этом случае он отклонил толчок, но это может быть конус

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