Como se livrar do branch de desenvolvimento para o fluxo Git simplificado

Em um projeto web continuamente desenvolvido (não um produto), atualmente temos a seguinte estratégia de ramificação, basicamente baseada no fluxo git :

• desenvolver filial: versão de trabalho mais recente
• ramificação mestre: versão a ser lançada / versão lançada
• ramos de recursos: recursos em desenvolvimento
• ramos de hotfix: correções urgentes na versão lançada

O mestre é somente leitura, atualizado por meio de solicitações pull de ramos de desenvolvimento ou hotfix . Cada atualização resulta em um candidato à liberação sendo construído e implantado no sistema intermediário. Os candidatos a liberação são implantados na produção após aprovação manual.

As ramificações de recursos são criadas com base no desenvolvimento ou no último commit que foi mesclado no master. É criada uma solicitação de recebimento de um ramo de recursos a ser desenvolvido, implantada em um sistema de teste gratuito, onde são executados testes de integração e testes de aceitação (automático e manual). Quando testado e revisado com sucesso, o PR é mesclado, para que ele se torne parte do próximo lançamento (ou seja, mescla do desenvolvimento para o mestre).

Meu gol

Gostaria de simplificar isso e me livrar do ramo de desenvolvimento. O ramo de desenvolvimento tem razões históricas e, como sempre é uma versão testada com êxito, acho desnecessário mantê-lo separado do mestre. A remoção também simplificará o processo de liberação, porque não há mais mesclagem adicional.

Eu tenho as seguintes restrições:

• os lançamentos estão agendados e não devem ser totalmente automatizados
• enquanto as ramificações de recursos geralmente têm vida curta, algumas permanecem inalteradas por várias semanas (por exemplo, uma reformulação), mas também precisam ser testadas (atualmente, como solicitações de abertura aberta para desenvolvimento)
• Às vezes, um único recurso deve ser lançado fora da versão regular, transformando-o efetivamente em um hotfix. Com a estratégia atual, posso refazer uma ramificação de recursos e mesclá-la diretamente no mestre
• também acontece que precisamos reter os recursos após os testes de aceitação com sistemas externos na preparação falharem

Onde não tenho certeza sobre a transição:

• Atualmente, estou criando solicitações pull para testes e mesclagem de confirmações. Posso unificar isso?
• como lidar com hotfixes quando o mestre estiver à frente da versão mais recente. Devo criar e implantar versões diretamente de ramos de hotfix?
• existe uma maneira sensata de lidar com recursos que devem ser excluídos de um release depois que eles já foram mesclados? Um ramo de desenvolvimento separado é realmente uma vantagem para esses casos? Na maioria das vezes, acabo revertendo e revertendo os commit manualmente de qualquer maneira.

IMHO, os problemas que você está enfrentando são apenas um efeito colateral da fraca estratégia de filial com a qual você começou: você está efetivamente desenvolvendo um novo desenvolvimento develop(isto é, o que converge para o futuro código de produção) através do código de produção atualmaster . Isso leva a requisitos e problemas contraditórios, pois normalmente o código futuro diverge do código atual:

• o novo desenvolvimento desestabiliza produção - regressões visto após a fusão developemmaster
• estabilizar a produção atrasa o desenvolvimento futuro - você precisa se estabilizar developpara torná-lo bom o suficiente para se fundirmaster

Soltar developnão ajuda (muito) - você não está eliminando o problema, apenas transferindo a developparte específica do problema master.

Uma abordagem melhor seria mover a produção para trás do desenvolvimento atual / futuro, para evitar interferência no desenvolvimento de versões futuras, conforme ilustrado nesta imagem de Qual é o seu modelo de ramificação? :

Observe que estou me referindo apenas aos ramos de liberação na imagem acima, não ao que está acontecendo no porta-malas.

Como isso funcionaria para você:

• o developramo desaparece, como você desejou, absorvido emmaster
• o masterramo é seu tronco, é aqui que o desenvolvimento acontece sem restrições de velocidade ( nunca é mesclado à produção).
• a produção é / é um ou mais releaseramos extraídos de uma masteretiqueta / etiqueta considerada próxima o suficiente da qualidade da produção (uma pequena lista de itens de tarefas restantes pode ser endereçada nesse ramo, se necessário). Essas ramificações só podem receber hot-fixes diretos e / ou escolhidas por cereja master, nunca são mescladas com masteroutras ramificações
• hotfixes são confirmações diretas em releaseramos

Se um hotfix se aplicar apenas a uma versão de produção, mas não ao, masterele será diretamente confirmado na releaseramificação. Se for aplicável a ambos, ele normalmente está comprometido com o masterprimeiro e com seleção dupla / com confirmação dupla para a releasefilial.

Agora, olhando para o que entra master(que passou do ponto em que a releaseramificação atual é retirada), você tem 2 opções:

• continue com ramificações de recursos, como você faz hoje, exceto que elas serão baseadas master, não develop. Ainda é possível convertê-los em hot fixes - você só precisa redimensioná-los para a releaseramificação correspondente em vez demaster
• mude para a integração contínua e colha seus benefícios (pode ser feito a qualquer momento), inclusive de maneira progressiva - puxe gradualmente cada vez menos ramificações de recursos.

Se você gosta dessa abordagem, veja como chegar de onde está hoje:

• estabeleça uma estratégia de nomeação de release:
  • você não pode ter um ramo de lançamento em andamento com o mesmo nome
  • você não pode (não deveria) rebase ou sincronizar uma ramificação de liberação de produção
• puxe um releaseXramo masterimediatamente, seguindo essa estratégia de nomeação
• parar os commits de entrar develop, logo eles vão direto para master.
• fundir develop- se emmaster
• instrua os desenvolvedores a refazerem seus espaços de trabalho em mastervez de develop.
• aberto masterpara confirmações
• exclua developse desejar (ou deixe permanentemente bloqueado / somente leitura para referência)

Digamos que você retire a ramificação principal (você pode renomear o develop para master para confundir sua equipe, se desejar mais tarde) e simplesmente use tags para liberações nas ramificações de desenvolvimento ou hotfix. Você efetuou uma ramificação, mas a diferença é apenas uma alteração na sintaxe. Mude para mudar.

Agora, digamos que você efetue o desenvolvimento mantendo o ramo mestre bloqueado. O que acontecerá é que a integração do código diminuirá, viverá mais tempo separada nas ramificações dos recursos, especialmente perto das datas de lançamento. Isso aumentará a dificuldade de mesclar a cada vez e atrasará o processo.

Dentro das restrições que você estabeleceu, não vejo efeitos positivos de fazer essa mudança. Exigiria relaxar as restrições, especialmente a primeira.

Você já está construindo e testando o código em cada uma das ramificações de solicitação de recebimento e hot-fix. Isso significa que, em conjunto, a soma de todas as ramificações pendentes na solicitação de recebimento é sua developramificação virtual .

Você pode criar um sistema quando, em um ambiente de teste, várias solicitações pull são selecionadas em uma ramificação temporária que não é publicada no repositório principal. Essa ramificação é usada para integrar um ambiente de teste que inclui mastervárias solicitações pull adicionais, mas depois que o teste é concluído, essa ramificação não está mais disponível em nenhum lugar.

Quando você cria uma versão master, geralmente cria uma tag nessa versão. Os hotfixes posteriores podem usar essa tag para criar uma nova ramificação de hotfix a partir da qual uma implantação será feita, mesmo que a borda do masterjá esteja à frente. Nesse ramo de hotfix, você provavelmente também marcaria uma versão secundária e verifique se as alterações foram mescladas master.

A remoção de recursos mesclados de uma versão é bastante difícil de fazer com o git. O melhor mecanismo para isso seria usar git reverto commit de mesclagem. Mas isso torna quase impossível recuperar esses recursos / mudanças, e a história se torna confusa.

Uma maneira muito melhor de lidar com a separação para implantação de código e liberação de recursos é com os sinalizadores de recursos . Se seus desenvolvedores puderem ocultar seus recursos por trás de algumas condições no próprio código, você poderá implantar o código, mas desative o recurso. Este é um tópico separado, mas existem muitas informações sobre isso (incluindo perguntas e respostas sobre devops.SE).

Bem, o @ dan-cornilescu diz isso bem para o seu problema específico, mas o caso mais geral de desenvolvimento baseado em tronco (mencionado no Continuous Delivery, Lean Enterprise e DevOps Handbook) é feito aqui: https://trunkbaseddevelopment.com/