Рабочий процесс Git с Capistrano

Question

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

Вот то, что я имел в виду до сих пор, но я пойман, когда сливаюсь обратно в основную ветвь (т. Е. Перед переходом на сцену? После?) И пытаюсь подключить ее к capistrano для развертываний:

1. Убедитесь, что вы в курсе всех изменений, внесенных в удаленную главную ветку другими разработчиками
   • git checkout master
   • git pull
2. Создайте новую ветку, которая относится к конкретной ошибке, которую вы пытаетесь исправить
   • git checkout -b bug-fix-branch
3. Внесите изменения
   • git status
   • git add .
   • git commit -m "Friendly message about the commit"

Итак, обычно это где я получаюзастрял.На данный момент у меня есть ветка master , которая исправна, и новая ветка bug-fix-branch , которая содержит мои (не проверенные - кроме модульных тестов) изменения.

Если я хочу перенести свои изменения на стадию (через cap staging deploy), нужно ли мне сливать свои изменения обратно в ветку master (я бы предпочел этого не делать, поскольку кажется, что мастер должен быть свободен от непроверенного кода)?Могу ли я даже выполнить развертывание с мастера (или я должен сначала пометить выпуск, а затем изменить файл production.rb для развертывания из этого тега)? git-deploy , кажется, решает некоторые из этих проблем рабочего процесса, но я не могу понять, как на самом деле он зацепляется за промежуточное развертывание и конечное развертывание.

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

Помогите!

Answer 1

Способ, которым я это делаю, заключается в том, чтобы иметь «промежуточную» ветку, которая отслеживается в вашем благословенном репо.Вы захотите использовать гем 'capistrano-ext', который предоставляет несколько дополнительных опций конфигурации для этапов (я думаю, что вы уже используете это, учитывая ваш вызов для развертывания в стадии подготовки).capistrano-ext определяет этапы, которые позволяют вам иметь файл развертывания для каждого этапа, например, «этап», где вы определяете ветвь set :branch, "staging", уникальную для каждого этапа, на который вы развертываете.Вы можете сделать свой рабочий процесс выше и добавить:

#after commiting on bug-fix branch
git checkout staging # => tracks staging on origin
git merge bug-fix-branch # => bring new code in
git push origin staging # => capsitrano acts locally, it needs the code to get from origin
cap staging deploy # => wasnt that easy?

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

• мастер - крайний код, в котором команда делится между разработчиками
• staging - код, который должен быть протестирован клиентом на промежуточном сервере (ускоренные пересылки при слиянии master)
• production - стабильный выпуск (fastforwards fromstaging)

РЕДАКТИРОВАТЬ: ответ на комментарий был слишком длинным, поэтому мне пришлось добавить к ответу.

У вас есть несколько способов справиться с этим, я могу придумать одинсразу.Исправление на prod должно быть отражено во всех ветках как можно скорее, чтобы ваши разработчики работали на одной базе.Предполагая, что prod имеет прямого общего предка для подготовки и подготовки к master, исправление prod должно быть добавлено в ветку темы на основе HEAD ветви prod, затем объединить это изменение с master и затем в staging и, наконец, для развертывания впроизводство.Идея состоит в том, что единственная разница - это коммиты для исправления ошибки, в следующий раз, когда вы перенесете производство в голову при постановке, у вас уже будет объект, который представляет собой изменение от исправленной ошибки, так что проблем нет.(и поскольку есть хорошая проверка на ошибку, вы знаете, что она работает, после запуска пакета в каждой ветви).В противном случае вам, вероятно, придется выбрать коммит от мастера и применить его к Prod и Staging.Взгляните на pro-git.org, чтобы узнать о более продвинутых рабочих процессах.