O que acontece se um recurso mesclado ao desenvolvimento for adiado pelo gerenciamento?

53

Recentemente, tivemos um problema em que um recurso para nosso aplicativo da web (inscrição automática) foi adiado pela gerência porque eles sentiram que o início estava muito "frio", mas eles queriam que todos os outros recursos em que estivéssemos trabalhando fossem lançados.

O problema é que essa funcionalidade foi mesclada no desenvolvimento quando foi concluída, juntamente com todos os outros recursos que esperávamos lançar no próximo lançamento, para que não pudéssemos apenas mesclar dev -> test -> master como costumamos fazer.

Como poderíamos ter evitado esse problema?

project-management git gitflow Steve
fonte
Dependendo do seu ponto de vista de como você deseja resolver isso, essa pergunta é mais adequada ao local de trabalho, se você não estiver procurando uma solução técnica.
Malavos 03/09/2015

Respostas:

74

Uma abordagem é o recurso de sinalização. Ele pode viver na base de código, mas ser desativado pela configuração.

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

Daenyth
fonte
9
A sinalização de configuração não implica uma duplicação do esforço de teste para esse código? Você precisa testar os dois caminhos.
16
Nesse caso, como você não ativará esse sinalizador na produção, poderá testar o caso desativado agora para o lançamento e testá-lo quando estiver pronto para ir para o prod. Esse deve ser aproximadamente o mesmo trabalho que testar uma reversão e nova confirmação.
Alan Shutko
4
O termo comum é Alternância de recursos . Se houver um pequeno "ponto de entrada de recurso", isso provavelmente poderá ser feito após a decisão de gerenciamento. Caso contrário, também haverá problemas com este método e com qualquer método.
Doc Brown
3
Temos recursos em desenvolvimento há mais de 6 meses Feature Toggling, como oculto por Doc Brown. Isso também nos permite testar o recurso (ou ausência dele) em ambientes de não produção. Às vezes, esses recursos se somam aos recursos existentes; nesse caso, devemos fazer testes de unidade para o conjunto de recursos antigo e novo. Cada teste de unidade definiria o sinalizador para o que for necessário para o teste atual.
Ps2goat 02/09/2015
25

Como poderíamos ter evitado esse problema?

Da perspectiva do processo, descubra:

  • Quem foi o tomador de decisão para iniciar este trabalho?
  • Por que a decisão de liberar esse recurso foi alterada?
    • Perdeu as expectativas?
    • Falta de comunicação?
    • Suporte comercial inadequado?
    • Sem envolvimento do cliente?

Mais do que provável, houve quedas na comunicação ao longo do caminho. É importante ter isso, porque, quando não funcionar, seus processos de desenvolvimento serão baseados em entendimentos falsos e errados dos requisitos de negócios.

enderland
fonte
9
+10. Assim que o gerenciamento começou a duvidar do lançamento do recurso, eles deveriam ter informado os desenvolvedores, para que a possível remoção pudesse ser levada em consideração ao decidir mesclar o recurso ao desenvolvimento.
Bart van Ingen Schenau 02/09/2015
14
Esta não é uma resposta muito construtiva - às vezes as coisas vão para o lado por todos os tipos de razões. Claro, descobrir que não deve ser mesclado mais cedo ou mais tarde é importante, mas isso não significa que, eventualmente, um recurso será puxado no último minuto. Talvez as mudanças de contrato, talvez o seu cliente não pagar, talvez questões legais aparecer .. você ainda tem que gerir o problema em vez de apontar o dedo da culpa
gbjbaanb
11
Se houver pessoas em sua organização que sejam suficientemente poderosas para se recusar a admitir falhas e também sejam infantis o suficiente para não querer evitar falhas, você ainda deverá ter problemas post-mortem para suas próprias informações. Você simplesmente não quer contar a eles (ou anotá-los explicitamente). Dito isto, enderland não usa a palavra "culpa" e, se a organização interpreta esse conselho como "descobrir quem é o culpado", isso é um problema para a organização. Tudo o que diz é "entender por que o problema ocorreu", essencial para evitá-lo no futuro.
Steve Jessop
2
Concordo plenamente, este é um erro de gerenciamento, não um de desenvolvedor.
precisa saber é o seguinte
3
@enderland O que quero dizer é que você não pode evitar alguns problemas, então você deve considerar como reparar a situação. Espero que você não chegue tão longe com muita frequência, mas isso acontecerá mais cedo ou mais tarde, de modo que planeje adequadamente.
gbjbaanb
19

Esqueça por um momento o problema com 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 Git?

Eu acho que você declararia "desabilitar a inscrição automática por configuração" simplesmente como um recurso adicional (é apenas uma forma de alternância de recursos ); portanto, isso deve se integrar perfeitamente ao seu fluxo de trabalho. Você pode estimar o esforço, se desejar, pode usar uma ramificação de recursos para ela (ou não, se não usar ramificações de recursos para esses problemas). E você pode definitivamente usar o fluxo "mesclar dev -> test -> master" que você descreveu.

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

Doc Brown
fonte
Fowler tem uma saída realmente boa, mas não posso suportar esse método para introdução de recursos. O esforço coordenado para tais opções parece ser um fardo desnecessário. I pode apoiar acrescentando alterna recurso para remover recursos após a fusão, mas a construção de um interruptor como parte da exigência faz-me desconfortável.
Gusdor
@ Gusdor: veja minha edição.
Doc Brown
1

Esse é o problema exato que tenho com o gitflow e o fluxo do GitHub, e parece que com 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 'bundle branches' além dos branches padrão do gitflow. O pacote configurável consiste em todos os recursos que estão prontos para o uat / qa. Uma lista de recursos uat / qa é criada. Eles são mesclados no pacote temporário e esse pacote é implementado no uat / qa. Qualquer correção de bug ocorre na ramificação do recurso original e é reenviada ao pacote configurável e implantada. Isso separa a próxima versão, além de permitir testar esses recursos juntos antes que eles encontrem o caminho para o ramo de desenvolvimento. As ramificações aprovadas desenvolvem uma solicitação de recebimento - seguindo o processo do gitflow. Os recursos prontos para teste podem ser adicionados ou removidos da ramificação do pacote temporário e reimplementados.

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

Os contras incluem gerenciar a lista de pacotes configuráveis ​​e adicionar outro tipo de filial; no entanto, além da correção retro, que acho tarde demais, esta parece ser a solução mais viável.

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

David Latty
fonte