Процесс разработки, развертывания, GitHub - PullRequest
Новая
       28

Процесс разработки, развертывания, GitHub

4 голосов
/ 22 ноября 2011

Я пытаюсь ускорить процесс разработки для нашей команды.

У нас есть 3/4 разочарованных разработчиков, работающих над нашей базой кода в любое время.

Мы начали использовать GITи идея в том, что часть работы - это больше, чем исправление в реальном времени, тогда они разветвляют основную ветвь.

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

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

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

У нас есть только 1 работающий сервер, хотя было бы неплохо, если бы только измененные файлы в основной ветке могли быть развернуты наживой сервер.

Есть идеи, как это сделать?

Этот подход оправдан?

Любые другие комментарии / предупреждения?

Необходим балансировщик нагрузкиделать такие вещи?

1 Ответ

4 голосов
/ 24 ноября 2011

Моя компания подписана на этот блог .

Мы создаем ветку master для производства. Мой случай для веб-разработки .

Шаг, который мы делаем, это

Разработчик разветвляет свою особенность / ошибку от master 

git checkout -b feature/featureA
git checkout -b bug/B

Таким образом, мы получим новый код с уже выпущенной строкой. В промежуточном сервере мы используем testing branch. Таким образом, когда любая функция хочет пройти тестирование, она объединится с этой веткой

В промежуточном сервере мы используем 

git checkout testing
git pull

Существует ветвь release , которая обрабатывает оперативное исправление, каждое оперативное исправление будет сливаться с этой ветвью перед слиянием с мастером. Идея состоит в том, что ветвь релиза будет упаковывать некоторые коммиты перед слиянием с мастером, которые в случае возникновения проблемы просто используют команду типа 

git reset --hard HEAD^

для временных.

Давайте посмотрим на мой полный рабочий шаг 

git checkout master # Go to Master
git checkout -b feature/New  # New branch

Письмо пришло от босса, чтобы исправить критическую ошибку 

git stash 
git checkout master
git checkout -b hotfix/a

делать вещи 

git commit
git checkout release
git merge hotfix/a
git checkout master
git merge release # In case that you want to pack all ready to production

В производстве 

git tag -d previous
git tag previous
git pull

Oops! не работает 

git checkout previous

Новый коммит слит 

git checkout master
git pull

Продолжить мою работу 

git checkout feature/New
git stash pop #Restore workspace
git commit
git checkout testing # ready to mix a test
git merge feature/New

Готов к выпуску функции 

git checkout release
git merge feature/New

Это потому, что все в ветке тестирования готово к развертыванию. Итак, когда объединить все готовые функции в ветку release , теперь вы можете сделать окончательный тест.

Когда все сейчас идет в производство, мы делаем 

git checkout testing
git merge master
git checkout release
git merge master

Автоматизировать скрипт

Я думаю, что вы можете заглянуть в .git/hooks/post-commit.sample для того, чтобы подключить какой-нибудь скрипт после фиксации кода? во всяком случае, я никогда не использую его.

...