Estratégia de ramificação Git para código não lançado de longa duração

Em nossa equipe, além de unidades de trabalho individuais (Histórias), temos temas de trabalho de duração mais longa (Epics). Várias histórias são épicas.

Tradicionalmente, tínhamos ramificações de recursos para cada história e as fundíamos diretamente para serem dominadas quando elas passavam no controle de qualidade. No entanto, gostaríamos de adiar o lançamento de histórias concluídas em uma epopeia até que a epopéia seja considerada "recurso concluído". Só lançaríamos esses recursos para produção quando toda a Epic estivesse fechada. Além disso, temos um servidor de construção noturno - gostaríamos que todas as histórias fechadas (incluindo aquelas que fazem parte de épicas incompletas) fossem implantadas automaticamente nesse servidor noturno.

Existem sugestões sobre como gerenciar nosso repositório para conseguir isso? Eu considerei a introdução de "ramificações épicas", onde combinaríamos histórias fechadas com a ramificação épica relacionada em vez de direta para dominar, mas minhas preocupações são:

• Preocupo-me com os conflitos de mesclagem que podem surgir se ramificações épicas forem mantidas abertas por muito tempo
• As construções noturnas exigiriam a fusão de todas as ramificações épicas em uma ramificação "construção noturna". Novamente, conflitos de mesclagem podem surgir, e isso deve ser feito automaticamente

Sugestão simples: não faça isso.

As ramificações git não são para garfos de código demorado, como discutido aqui e https://blog.newrelic.com/2012/11/14/long-running-branches-considered-harmful/ . As ramificações são melhor tratadas como coisas transitórias usadas para organizar confirmações por um desenvolvedor individual no nível do dia-a-dia. Portanto, se eles tiverem um nome que corresponda a algo que um gerente de projeto (sem falar no usuário final) possa se preocupar com o fato de você estar fazendo algo errado.

A prática recomendada é usar a integração contínua com alternância de recursos ou ramificação por abstração para garantir que:

• todo o código é integrado o tempo todo (pelo menos todos os dias, de preferência com mais frequência)
• o que é implantado está sob controle explícito.

Eu acho que esse é um problema bastante comum e se resume a escolher quais recursos incluir em um release depois que os recursos foram codificados e não antes.

por exemplo.

Eu tenho os recursos A, B e C da v2 do meu produto. B e C estão relacionados, não quero liberar B, a menos que C também esteja concluído.

Eu tenho três desenvolvedores trabalhando ao mesmo tempo nos recursos.

Eu tenho um conjunto na data de lançamento de pedra D

B está terminado e fundido, A está terminado e fundido. C está atrasado ... o que eu faço ?!

Não acredito que haja uma solução técnica para esse problema. Você deseja liberar uma versão não testada do produto com apenas o recurso A incluído. A menos que você mescle e teste todas as combinações possíveis de recursos, isso sempre será uma possibilidade.

A solução é mais humana. Você perdeu sua data de lançamento e deve devolvê-la.

Este é um problema complicado, mas que muitas pessoas enfrentam. Prefiro usar a configuração do Gitflow como ponto de partida.

Desenvolvimento -> Novos itens sendo trabalhados no
Master -> Novos itens que precisam ser testados Produção -> Novos itens publicados na produção.

Em recursos menores (mais curtos), crio uma ramificação a partir do desenvolvimento, faça o trabalho lá e, em seguida, mesclamos a ramificação de volta ao desenvolvimento.

Nos principais recursos (a longo prazo), crio uma ramificação a partir do desenvolvimento, crio ramificações menores a partir dessa ramificação e, em seguida, volto à primeira ramificação. Depois que o recurso principal estiver concluído, volte ao ramo de desenvolvimento.

A intervalos regulares (depende do projeto), mesclo o desenvolvimento novamente ao mestre e um ciclo de testes começa. Se alguma correção surgir no teste, ela será feita na ramificação principal (sub ramificação e mesclada). E o desenvolvimento pode continuar na ramificação principal durante o teste.

A qualquer momento, o mestre deve ser mesclado ao desenvolvimento, e o desenvolvimento deve ser mesclado a qualquer um de seus sub-ramos de longo prazo.

o mestre deve sempre (em teoria) estar pronto para a produção. O desenvolvimento deve sempre (em teoria) estar pronto para a produção. A única razão pela qual existe uma diferença é fornecer um conjunto sólido de recursos para os testadores testarem.

Quando pronto, uma consolidação no mestre que é testada é mesclada à produção e a implantação na produção acontece a partir dessa ramificação. Os HOTFIXs que precisam ser executados em uma emergência podem ocorrer no ramo Produção sem ter que mesclar no mestre (que pode ter muitas alterações não testadas).

Minha árvore normal parece

 LongTerm -> Development -> Master -> Production    
 LongTerm <- Development      |            |  
     |       Development -> Master         |  
 LongTerm <- Development -> Master         |  
             Development <- Master         |  
                            Master -> Production  

É minha regra geral que nenhuma mudança isolada demore mais do que algumas horas. Se isso acontecer, ele precisará ser transformado em alterações menores. Se é um recurso imenso (como uma reescrita da interface do usuário), isso ocorre a longo prazo, para que o desenvolvimento normal possa continuar ao mesmo tempo. As ramificações LongTerm normalmente são apenas ramificações locais, enquanto Desenvolvimento, Mestre e Produção são ramificações remotas. Quaisquer sub-ramificações também são apenas locais. Isso mantém o repositório limpo para outras pessoas, sem perder a utilidade do git em um conjunto de recursos de longo prazo.

Gostaria de observar, no entanto, que a existência de um ramo de longo prazo é algo raro. Normalmente, todo o meu trabalho está em desenvolvimento. Somente quando tenho um recurso (conjunto) que levará tanto tempo que também preciso trabalhar em coisas normais de desenvolvimento, devo usar o ramo LongTerm. Se é apenas um conjunto de mudanças que devem estar juntas, simplesmente não me fundo até que tudo esteja pronto.