(git) Как организовать работу локальной и production версии сайта?

Question

[Василий Г.]

Здравствуйте.
Нужна помощь в настройке работы с сайтом.

Сейчас сделано так:
1. Развернул виртуальную машину VirtualBox c консольной CentosOS, настроил там вебсервер.
2. На компе стоит Windows и редактор phpStrom, установлено соединение c виртуальным сервером. Все изменения автоматом загружаются на локальный сервер.
3. Есть аккаунт на gitlab.com, куда я выгружаю все изменения с локального сервера.
4. На продакшине (site.com) делаю git pull с gitlab.com

Как можно улучшить этот процесс?
Хочу еще сделать бета домен (напр. beta.site.com), сначала туда выгружать новый функционал, тестировать, показать заказчику и уже потом выгружать все на продакшн.

Какие можно почитать полезные статьи?

Comments

[Silm]

А что оптимизировать этот процесс? Вроде ничего лишнего.

Answer 1

[evnuh]

Я уже четвёртый раз отвечаю на подобный вопрос:

Собсно, как делаем мы - toroid.org/ams/git-website-howto . Это процесс деплоя. В свой локальный репозиторий добавил два ремоута - prod & test. Это помимо origin, который указывает на ваш общий bare git репозиторий, на гитхабе, например. Собсно сначала выкладываю на тест одной командой
git push test master
потом, если всё хорошо, уже на прод
git push prod master
Если нужны какие-нибудь пост-обработки, то они происходят на сервере через хуки гита.

По поводу workflow. Простейший вариант - Github Flow.
Есть одна ветка, master - там всегда то, что сейчас на проде.
Чтобы сделать фичу/починить баг вы создаёте новую ветку из мастера, коммитите в неё, когда всё сделали мерджите её в мастер. Перед мерджем, понятное дело, обновите свой мастер, вдруг кто-то туда уже смерджил свою ветку с другой фичой. Хотите перед мерджем протестировать свою фичу?
git push test my-feature:master
это запушит вашу ветку на тестовый сервер.

Comments

[Sergey Zhukov]

Я правильно понимаю, что есть разница от того, мержим мы test с master или master с test?

[evnuh]

Сергей Жуков: конечно есть. Код на выходе будет одинаковый, только он будет в той ветке, в которую вы мержите, другая останетсяя без изменения.

Answer 2

[Антон Тихомиров]

У меня все просто как топор! Имеется батник с прописанными командами
git commit, git push, git pull, и далее по ситуации, который запускается автоматически в момент сборки проекта (короче когда запустишь))) ), он все коммитит на Гит, и он же деплоит все на удаленный сервер по sFTP (который по SSH c сертификатами) c помощью консольной утилиты winscp (ибо sFTP) с явками из отдельного конфига, который лежит вместе с батником, поэтому его можно легко изменять, не затрагивая сам батник. То есть отправили на Гит, все синхронизировали с локальной версией, если все норм - то развернули на удаленный. И все. Минус только один: пока работать можно только с одной веткой. Но это все только вопрос модернизации самого батника (у меня просто нет такой необходимости). Честно признаться, я не знаю, почему всем дают такие зубодробильные инструкции при ответе на вопросы такого рода, но как по мне - все гениальное просто. Не, исправьте меня если что, может быть я заблуждаюсь в своей правоте, я готов принять конструктивную критику такого подхода)

Answer 3

[Андрей]

git-flow