Как упростить схему деплоя?

Первый раз работаю в небольшой команде на внутрикорпоративном проекте. Изучить гит более-менее осилил. Теперь мучаюсь с деплоем. Суть такова:
Используем стандартную схему веток (master, develop, topic). Программируем и верстаем у себя на локалке. Есть боевой сервер. Он же и git-сервер. Он же и тестовый сервер :) Сервер содержит 2 веб-приложения. Первое мы пуллим из master-ветки — релиз готов, второе — из develop — тестируем, прежде чем мастер пулить.
Так вот, чтобы банально выложить малюсенькое изменение feature ветки в продакшн (или хотя бы в тест) мне приходится превозмогать рутину:
Переключиться с feature на develop, обновить ветку. Смержить feature, запушить develop Переключиться на master, обновить её Смержить develop, запушить master Подключиться к боевому серверу сделать пулл на develop-приложении Подключиться к боевому серверу сделать пулл на master-приложении ??? "А тут ещё букву поправьте, пожалуйста" goto 1
Это можно ли как-то всё упросить? Я уверен, что-то делаю неправильно.

Ответ

Пункты 1-2 - это очень упрощенный (где убрано к примеру тестирование) процесс, который делает каждый разработчик. Это его обычный цикл.
Пункт 3-4 - это релиз. Он не должен делать обычным разработчиком. Он делается релиз-менеджером (или ответственным человеком, назначенным на этом). Он не делается на каждый чих, а по процессу - раз в две недели или два раза в день
Пункты 5-8 делаются нажатием одной (максимум двух кнопок) или запуском одного скрипта. Он запускается на специальном билд сервере (для маленькой такой компании это может быть одна машина и для сборки, и для тестов и для репозитория). Сам скрипт сборки обычно делает следующее
git clone / git archive прогон скрипта, который фиксит конфиги, шаблоны (вы же не хотите показывать всем программистам пароли к базе на проде?) запуск скрипта, который процессит css, минимизирует js и тому подобное. прогон юнит тестов (они здесь, так как после минимизации могут быть проблемы:) ) архивирование и занесение архива в надежное место подключаемся к прод серверу(серверам) и заливаем туда архив. архив распаковывается на сервере в отдельную папку, правится конфиг nginx/apache или симлинка и сервер рестартует. (можно конечно остановить сервер, перетереть файлы и запустить сервер, но если что то пошло не так...). на проде проганяются минимальные тесты (к примеру, что главная страница возвращает 200 код, а не 500). и в git добавляется тег с ссылкой на релиз.
Этот скрипт пишеться один раз и потом подганяется по мере надобности.
также этот скрипт следует дополнить, что бы он мог работать и с develop веткой.
Теперь упрощаем жизнь. В хуки на гит сервере добавляем этот скрпит, что бы при пуше в девелом/мастер автоматом запускалось и, как результат, деплоилось на тестовый сервер/прод. Мердж в мастер обычным программистам запрещается.
Теперь все выглядит так. Разработчик взял фичу, сделал под нее ветку, сделал. После мержда в девелом (или через мердж реквест) его код автоматом выливается на тестовое окружение. Если вдруг так случилось, что он все сломал - он должен фиксить.
Если так не подходит, можно скрипт запускать на CI - один с самых популярных - jenkins. В результате деплой - это просто нажать одну кнопку.
Q/A
а почему не пулить прямо на боевом сервере? Если кто то уведет сервер, у него будет доступ к полной истории разработки. Это нужно? у меня никто не уведет историю гита, поэтому я буду пулить. уже было зачем сколько сложностей с скриптом? А представьте, что багу нашли среди ночи и нужно срочно фиксить. Наличие такого скрипта сильно упрощает жизнь. а можно без тестов? можно. Но лучше сделать какие-то минимальные.