Git deploy. Много разработчиков против одного сайта с админкой

Здравствуйте. Как вы разворачиваете код из git'а? Например, в гите лежит сайт. Над этим сайтом работает команда разработчиков. Все они правят код и отправляют коммиты. Естественно, нужно иметь возможность быстро и легко развернуть свежую версию сайта на (тестовом) сервере.

Гугл по запросу git deploy даёт мне кучи одухотворённых статей о том, как легко и весело можно поселить сайт в репозитории. Это работает, если я единственный разработчик. А как быть, если нас команда?

При попытке сделать git pull в репозитории, в котором лежит сайт, периодически возникают проблемы с правами. Так как репозиторий тот инициализирован другим пользователем. Да и не красиво это.
Ещё можно завести отдельного пользователя для стягивания изменений в репозиторий. Это решает первую проблему, но не решает более существенную: когда через админку зальют некий файл — git pull уже не пройдёт. Нужно будет пушить изменения в хранилище, а это не всегда уместно. Добавление каталога с ними в исключения тут не поможет — через админку может измениться уже существующий на сервере файл.

Как быть?
  • Вопрос задан
  • 4303 просмотра
Пригласить эксперта
Ответы на вопрос 2
Exorcist
@Exorcist
Для таких целей можно и нужно использовать capistrano или что то похожее.
Ответ написан
@b0beR
Я считаю, что наиболее удобный способ использовать post-receive хуки в центральном репозитарии гита (если таковой имеется), либо (если проект хостится на гитхабе) использовать post-receive url. При этом в деплой должны попадать изменения, залитые в одну конкретную ветку гита (для тестовой версии это чаще всего ветка develop).

Опять же, если над сайтом работает несколько человек, проблем не возникает, так как каждый сначала сам делает merge своих изменений в develop, после чего push ветки develop в центральный репозитарий.

Файлы, которые меняются из админки, не должны быть в репозитарии (логично добавить их в .gitignore) Если же предполагается, что в репозитарии должны лежать изначальные версии этих файлов, а затем они могут правиться из админки (не очень хорошая практика), то логичнее будет вместо например файла translation.xml добавить в репозитарий файл translation.tpl.xml, и уже в самом скрипте деплоя (который вызывается из хука), копировать этот файл в настоящий translation.xml. Если же он был изменен из админки, то это уже ваша проблема, как обрабатывать такие конфликты. В нормально спроектированной системе такого быть не должно.

Вообще, очень удобно сочетать такую систему деплоя с использованием git flow. Тогда в ветку develop будет попадать только код, готовый к тестированию (и соответственно сразу выкладываться на тест), а в master будет мерджиться только production-ready код из ветки develop (если все сделать грамотно, то из master'а можно автоматом выкладывать на релиз, главное чтобы туда никто кроме руководителя проекта не пушил)

P.S. Если интересно, могу написать статью про использование git flow совместно с post-receive URL гитхаба для выкладывания тестовой версии.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы