Como evitar o branchageddon com grandes organizações?

10

Como você evita uma situação de branchageddon ao trabalhar com grandes organizações?

Trabalhamos com várias grandes organizações financeiras cuja abordagem é não levar atualizações para o software, mas apenas patches de segurança altos / críticos e funcionalidade sob medida. Essas organizações receberão apenas patches e versões personalizadas entre as principais atualizações. As principais atualizações podem ter anos de diferença e custam altos custos. Essa abordagem faz com que nós (a casa do software) tenhamos uma ramificação do nosso código por cliente principal, que carrega todos os custos e ineficiências da ramificação a longo prazo.

Minhas perguntas à comunidade são:

Você já experimentou abordagens semelhantes de aceitação de atualização de seus clientes?
Que sugestões você tem para ajudar a trabalhar com essa abordagem?
Que sugestões você tem para ajudar a mudar as abordagens das organizações para receber atualizações de software?

release process branch

— Mark Wheeler
fonte

Ei Mark, parece que você tem um dilema interessante. Como você gerencia o desenvolvimento dessas atualizações por cliente? Você os desenvolve de maneira pontual para cada cliente ou é algo que você desenvolve e aplica a todos os clientes?

— 21418 PrestonM

Pessoalmente, posso procurar outro emprego nessa situação. Isso soa como um incidente de segurança esperando para acontecer ... Posso dizer que, para o fornecedor do appliance em que trabalhei, eles tiveram um bug grave que foi corrigido em uma atualização que, segundo informações, eles não poderiam ir. Eles queriam uma correção personalizada. Nós nos recusamos a criar um e dissemos que eles precisavam corrigir suas políticas de negócios - não lançaríamos um hotfix personalizado para um bug que já havia corrigido, para que eles pudessem evitar problemas políticos internos.

— James Shewey

Gerenciamos as atualizações específicas do cliente personalizado por meio de várias ramificações de código e atualizações de segurança de correção cruzada em todas as ramificações, e o código de ramificação de correção cruzada de volta ao tronco. Freqüentemente, o cliente A não aceita atualizações do cliente B em suas filiais, apenas as próprias atualizações e patches de segurança. Isso é motivado pelo desejo de estabilidade em suas ramificações e, portanto, eles só precisam testar atualizações relevantes para eles. Eles recebem atualizações de tronco com menos frequência (meses ou anos) quando estão prontos para executar repetições de teste completas, o que pode levar meses para ser concluído. Teste automatizado pode ser a resposta!

— Mark Wheeler

3

Como Michael mencionou, ofereça uma solução padrão baseada em versões / números de lançamento, com uma vida útil razoavelmente longa para o seu setor (talvez intercalada com uma ou mais versões intermediárias de vida útil mais curta, se isso fizer sentido para seus clientes típicos).

Dê a seus clientes a opção de embarcar nessa faixa de lançamento padrão, talvez com um prazo de migração decente.

Se eles insistirem em uma estratégia de suporte completo à filial, basta cobrá-los adequadamente, para cobrir adequadamente todos os seus custos extras por oferecer esse suporte completo - isso só faz sentido para os negócios. Alguns clientes migrarão para reduzir seus custos (o que o ajudará a reduzir o número de filiais personalizadas), outros não.

O faturamento de suporte variável, crescendo progressivamente com a idade das versões de lançamento das quais as ramificações personalizadas se originam também pode ser um incentivo para os clientes migrarem para ramificações mais recentes mais rapidamente, ajudando no fechamento mais rápido das ramificações personalizadas mais antigas. Isso pode ajudar a reduzir o número de filiais personalizadas por cliente - se você tiver clientes que executam simultaneamente várias versões do seu software.

Certifique-se de não cair na armadilha de fazer mesclagens de ramificações completas de / para qualquer uma das ramificações de liberação (padrão e personalizadas); todas as alterações nelas devem ser desenvolvidas individualmente ou corrigidas mescladas.

Como cada uma dessas ramificações diverge gradualmente uma da outra, o número de hotfixes que requerem personalização / desenvolvimento individual aumentará exponencialmente (a fusão simples de seleção de cereja falhará). Você precisa levar em consideração o custo de desenvolvimento.

Com nenhuma ramificação (significativa) mesclada na imagem, você pode (e não devo enfatizar sua importância o suficiente) criar pipelines de CI / CD totalmente automatizados para essas ramificações, acompanhados de um bom sistema de rastreamento / gerenciamento de hotfix, tornando a entrega do hotfix apenas rotina (ou quase).

— Dan Cornilescu
fonte

Dan - tão óbvio e simples, mas faz todo o sentido. O dinheiro faz o mundo girar e, por sua vez, deve ajudar a compensar o custo de filiais de longa duração ou incentivar os clientes a atualizar e ficar perto do tronco. Obrigado pelo seu bom conselho.

— Mark Wheeler

1

Talvez se você mantivesse ramificações por versões, em vez de por clientes, isso poderia ajudar a reduzir o número delas.

Caso contrário, a única maneira de realmente fugir dele é poder hospedar o software por conta própria e alternar para um modelo SaaS onde você seria capaz de manter apenas uma versão dele.

— Michael Pereira
fonte

Infelizmente, nossos clientes geralmente operam em ambientes muito fechados por causa dos dados financeiros com os quais estão trabalhando, portanto, um modelo SaaS não seria aceitável.

— 22618 Mark Wheeler