Хорошее развертывание Git с использованием стратегии веток с Heroku?

Какую стратегию развертывания использовать с Git + Heroku (Ruby on Rails)?

В настоящее время, как я работаю с моим исходным Git-репозиторием: все функции (или "истории") сначала извлекаются как ветки, затем объединяются с master и отправляются в origin.

Все, что отправлено в origin/master, запускает скрипт, который перетаскивает новый код rails в область подготовки (простой сервер rails).

Когда придет время отправить новую производственную версию в Heroku, должен ли я создать новую ветку (которая называется чем-то вроде production_version_121) и каким-то образом передать ее в Heroku?

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

Например, я не хочу, чтобы весь последний код был запущен в производство. Я мог бы захотеть добавить "a", над которым я работал, и функцию "c" как-то объединить в производство, не включая экспериментальную функцию "b", которая требует дополнительной отладки.

Н.Б. Сначала я попытаюсь избегать Капистрано и пока что-нибудь поработаю вручную.

есть идеи? Лучшие практики?

Ответ 1

В проекте Gemcutter мы просто имеем ветвь production. Любые изменения, которые мы хотим увидеть на производственном сайте, объединяются в эту ветвь, а затем развертываются с помощью:

git push heroku production:master

Разветвление staging служит аналогичной цели для промежуточного сайта (также на Heroku)

Ответ 2

С тех пор как я прочитал Vincent Driessen Успешная ветвящаяся модель Git, я был подключен. Вся моя компания (8 из нас) теперь стандартизовалась по этой модели, и несколько других мест, с которыми я консультировался, также начали использовать ее.

Большинство всех, кого я показал, говорит, что они уже делали что-то подобное, и нашли его очень легко адаптировать.

В двух словах у вас есть две ветки, которые являются постоянными (мастер и разработка). Большую часть времени вы просто создаете ветки, чтобы развить и слить их обратно в разработку. Все становится немного сложнее, когда вы занимаетесь производственными выпусками и исправлениями, но после прочтения сообщения пару раз, он становится укорененным.

Там даже инструмент командной строки, называемый git-flow, поможет вам.

Ответ 3

Существует множество способов сделать это, и это действительно зависит от ваших предпочтений.

Я дам вам одну возможную стратегию с самого начала: учитывая, что у вас уже есть автоматическая настройка, в которой используется мастер, я бы предложил создать ветвь "production". Когда вы хотите продвинуть исправление/функцию для производства, вы просто объедините ветвь темы в свою ветвь "production".

git checkout production
git pull . my-topic-branch
(resolve any conflicts)

Когда вы готовы на самом деле нажать этот код на ваш производственный сервер, вы должны tag ветку с использованием уникального имени (возможно, с временная метка). Затем вы просто нажимаете производственную ветвь на Heroku.

git checkout production
git tag release-200910201249

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

git config alias.dtag '!git tag release-`date "+%Y%m%d%H%M"`'

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

Вы можете просматривать теги с помощью git tag и просматривать их с помощью git show release-1234. Для получения дополнительной информации о тегах запустите git help tag. Вы также можете найти этот руководство Github по пометке. Я также рекомендую читать рабочие процессы других людей (здесь хорошая запись) и выбрать и выбрать, что сработает для вас.