Какую стратегию развертывания использовать с Git + Heroku (Ruby on Rails)?
В настоящее время, как я работаю с моим исходным Git-репозиторием: все функции (или "истории") сначала извлекаются как ветки, затем объединяются с master и отправляются в origin.
Все, что отправлено в origin/master, запускает скрипт, который перетаскивает новый код rails в область подготовки (простой сервер rails).
Когда придет время отправить новую производственную версию в Heroku, должен ли я создать новую ветку (которая называется чем-то вроде production_version_121) и каким-то образом передать ее в Heroku?
В идеале я хотел бы выбрать, какие функции из предыдущих версий разработки я должен включить в производственную ветку... протестировать его и перейти к Heroku.
Например, я не хочу, чтобы весь последний код был запущен в производство. Я мог бы захотеть добавить "a", над которым я работал, и функцию "c" как-то объединить в производство, не включая экспериментальную функцию "b", которая требует дополнительной отладки.
Н.Б. Сначала я попытаюсь избегать Капистрано и пока что-нибудь поработаю вручную.
есть идеи? Лучшие практики?
В проекте Gemcutter мы просто имеем ветвь production. Любые изменения, которые мы хотим увидеть на производственном сайте, объединяются в эту ветвь, а затем развертываются с помощью:
git push heroku production:master
Разветвление staging служит аналогичной цели для промежуточного сайта (также на Heroku)
С тех пор как я прочитал Vincent Driessen Успешная ветвящаяся модель Git, я был подключен. Вся моя компания (8 из нас) теперь стандартизовалась по этой модели, и несколько других мест, с которыми я консультировался, также начали использовать ее.
Большинство всех, кого я показал, говорит, что они уже делали что-то подобное, и нашли его очень легко адаптировать.
В двух словах у вас есть две ветки, которые являются постоянными (мастер и разработка). Большую часть времени вы просто создаете ветки, чтобы развить и слить их обратно в разработку. Все становится немного сложнее, когда вы занимаетесь производственными выпусками и исправлениями, но после прочтения сообщения пару раз, он становится укорененным.
Там даже инструмент командной строки, называемый git-flow, поможет вам.
Существует множество способов сделать это, и это действительно зависит от ваших предпочтений.
Я дам вам одну возможную стратегию с самого начала: учитывая, что у вас уже есть автоматическая настройка, в которой используется мастер, я бы предложил создать ветвь "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 по пометке. Я также рекомендую читать рабочие процессы других людей (здесь хорошая запись) и выбрать и выбрать, что сработает для вас.