O que acontece se uma característica incorporada no desenvolvimento for adiada pela gerência?

Uma abordagem é o recurso que sinaliza isso. Pode viver na base de código mas ser desativado pela configuração.

Outra opção é fazer um commit de reverter que reverte a junção do recurso para que ele não esteja mais em desenvolvimento. Uma nova ramificação pode ser feita, o que reverte a reversão e fica pendente para ser mesclada mais tarde. Se você estiver usando solicitações de solicitação do Github, poderá fazer isso facilmente com o botão "reverter mesclagem" em uma solicitação de recepção mesclada.

How could we have avoided this issue?

De uma perspectiva de processo, descubra:

• Quem foi o responsável pela tomada de decisões para começar este trabalho?
• Por que a decisão de liberar esse recurso mudou?
  • Expectativas perdidas?
  • Falta de comunicação?
  • Suporte comercial inadequado?
  • Nenhum envolvimento do cliente?

Mais do que provavelmente houve quedas na comunicação ao longo do caminho. Isso é importante porque, quando não funciona, seu (s) processo (s) de desenvolvimento será (ão) baseado em entendimento falso e errado dos requisitos de negócios.

Esqueça por um momento o problema com o seu gerenciamento e imagine que você já tinha o "recurso de inscrição automática" em sua última versão de produção, profundamente integrado à sua base de código. Agora você recebe o novo requisito para adicionar um "off-switch" para "inscrição automática". Como você lidaria com isso no seu fluxo de trabalho do Git?

Eu acho que você declararia "desativação da inscrição automática por configuração" simplesmente como um recurso adicional (é apenas uma forma de Alternância de recurso ), portanto, isso deve se integrar perfeitamente ao seu fluxo de trabalho. Você pode estimar o esforço, se quiser, pode usar um ramo de recurso para ele (ou não, se você não usar ramificações de recursos para tais problemas). E você pode definitivamente usar o fluxo usal "mesclar dev - > teste - > master" que você descreveu.

E é dessa maneira que você pode lidar com isso na sua situação atual. Do ponto de vista do fluxo de trabalho do git, não importa se a solicitação de mudança vem do gerenciamento para a liberação 1.0 ou se a solicitação de mudança é um novo desejo do cliente para a versão 2.0.

Este é o problema exato que eu tenho com o fluxo do gitflow e do GitHub, e parece que com os aplicativos da web isso acontece com frequência - ou mais como a norma. Parece que você resolveria esse problema retroativamente (mencionado acima) ou proativamente (exemplo abaixo).

Eu criei 'ramificações de pacote' além das ramificações de gitflow padrão. O pacote consiste em todos os recursos que estão prontos para uat / qa. Uma lista de recursos uat / qa é criada. Eles são mesclados no pacote temporário e esse pacote é implantado em uat / qa. Qualquer correção de bugs acontece no ramo de recursos original, e isso é remetido de volta ao pacote e implantado. Isso separa a próxima versão, bem como permite testar esses recursos antes de encontrar o caminho para o ramo de desenvolvimento. As ramificações aprovadas obtêm uma solicitação de pull no desenvolvimento - seguindo o processo de gitflow. Os recursos prontos para teste podem ser adicionados ou removidos do ramo de pacote temporário e reimplantado.

• Isso mantém o mestre sempre refletindo o estado pronto para produção (pode automatizar com gancho)
• O desenvolvimento sempre reflete o próximo candidato a lançamento entregue (e testado)

Contras incluem o gerenciamento da lista de pacotes e a adição de outro tipo de filial; no entanto, além da correção retro, que acho que é tarde demais, esta parece ser a solução mais viável.

Com um complemento de GUI, pode ser ideal marcar ramificações de recursos por implantação de pacote - com a automação em mente.