Boa implantação do Git usando a estratégia de filiais com Heroku?

Question

O que é uma boa estratégia de implantação para usar com Git + Heroku (Ruby on Rails)?

Atualmente, a maneira como trabalho com meu repositório Git de origem: todos os recursos (ou 'histórias') são verificados como ramificações e depois se fundem com o mestre e pressionados à origem.

Qualquer coisa pressionada para a Origin/Master aciona um script que puxa o código do novo Rails para a área de estadiamento (servidor da web do Rails Simple).

Quando chega a hora de empurrar uma nova versão de produção para Heroku, devo criar uma nova filial (chamada algo como Production_version_121) e pressionar isso de alguma forma para Heroku?

Idealmente, eu gostaria de escolher quais recursos de versões de desenvolvimento anteriores que eu deveria incluir no ramo de produção ... teste -o e empurre para a Heroku.

Por exemplo, posso não querer que todo o código mais recente seja pressionado para a produção. Eu posso querer características "A" em que eu trabalhei e apresenta "C", ambos se fundiram em produção de alguma forma, sem incluir o recurso experimental "B", que precisa de mais depuração.

NB Vou tentar evitar o Capistrano no começo e conseguir algo funcionando manualmente por enquanto.

Pensamentos? Melhores Práticas?

Answer 1

No projeto de gêmeos, simplesmente temos um Produção ramo. Quaisquer alterações que queremos ver no local de produção são fundidas nessa filial e depois implantadas com:

git push heroku production:master

o staging Branch serve a um propósito semelhante para o site de estadiamento (também no Heroku)

Answer 2

Desde que li Vincent Driessen Um modelo de ramificação Git de sucesso, Eu fui fisgado. Toda a minha empresa (8 de nós) agora padronizou neste modelo e alguns outros lugares que eu consultei também começaram a usá -lo.

Quase todo mundo que eu demonstrou diz que já estava fazendo algo semelhante e achou muito fácil de adaptar.

Em poucas palavras, você tem 2 ramos permanentes (mestre e desenvolvimento). Na maioria das vezes, você estará apenas criando galhos de desenvolvimento e fundindo -os de volta ao desenvolvimento. As coisas ficam um pouco mais complexas quando você começa a fazer lançamentos de produção e hotfixes, mas depois de ler o post algumas vezes, ele fica gravado.

Existe até uma ferramenta de linha de comando chamada Git-Flow para ajudá -lo.

Answer 3

Existem várias maneiras de fazer isso, e isso realmente depende da sua preferência.

Eu lhe darei uma estratégia possível de cima da minha cabeça: dado que você já possui uma configuração de preparação automatizada que usa mestre, sugiro criar uma filial de 'produção'. Quando você deseja promover uma correção/recurso para a produção, basta mesclar a ramificação do tópico na sua ramificação de 'produção'.

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

Quando você está pronto para realmente Empurre Esse código para o seu servidor de produção, você deve marcação a filial usando um nome exclusivo (provavelmente com um registro de data e hora). Então você simplesmente empurra o ramo de produção para Heroku.

git checkout production
git tag release-200910201249

Sugiro que a criação de um script ou alias git para automatizar a etiqueta para registros de data e hora, pois o uso de um esquema de nomeação consistente é importante. Eu uso algo assim:

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

Isso me permite fazer apenas digitar git dtag Quando eu quero marcar uma versão com um registro de data e hora.

Você pode ver suas tags usando git tag e veja -os usando git show release-1234. Para mais informações sobre tags, execute git help tag. Você também pode encontrar isso Guia do GitHub na marcação útil. Eu também recomendo ler os fluxos de trabalho de outras pessoas (aqui estão Uma boa redação) e escolha o que funciona para você.