Como convencer os desenvolvedores a começar a usar as alternâncias de sinalizadores de recursos?

Supondo que as alternâncias de sinalizador de recurso sejam uma boa ideia e deva ser implementada no código que os desenvolvedores escrevem. Por exemplo, Etsy jura por eles como uma parte importante de sua cultura .

Qual é uma boa maneira de persuadir (e impor) os desenvolvedores a começar a usar as alternâncias de sinalizadores de recursos?

Mais informações sobre alternância de sinalizador de recurso são explicadas em Q: Como usar alternância de sinalizador de recurso , Q: O que são alternância de sinalizador de recurso e muito extensivamente no artigo de Pete Hodgson sobre o assunto no blog de Martin Fowler .

A alternância de recursos é uma prática comum no desenvolvimento de alta velocidade, porque desacopla o desenvolvimento da liberação. As equipes de desenvolvimento podem "liberar" um novo recurso para produção, em um estado desativado. Isso permite que o recurso seja lançado a qualquer momento. Se o recurso depender de outro trabalho ou preparação, ele não precisará aguardar a liberação de um grande lançamento para produção.

Tanto quanto "convencer" os desenvolvedores a usá-los, esse é um exercício de defender a liberdade que ele oferece. Minha experiência é que não é uma venda difícil para os desenvolvedores. É a gerência que tende a relutar em tentar coisas novas. Tente o seguinte:

• Encontre uma estrutura de alternância de recursos. A gerência / empresa pode ser mais propensa a tentar algo suportado por um sistema comum
• Comece pequeno. Apresente o sistema de alternância, em caráter experimental, para um recurso que demonstre sua utilidade.
• Demonstre a capacidade do alternador de fazer testes A / B. Ative a alternância para um subconjunto do seu web farm e colete métricas de comportamento. Demonstrou-se que pequenas diferenças no layout da página causam enormes efeitos na receita de aplicativos de varejo (por exemplo, Ebay, Amazon)

Em um mundo ideal, acho que você lança uma nova compilação e surpresa! Nada muda. Isso ocorre porque todos os seus novos recursos estão atrás de interruptores que são desligados.

Após a implantação, você verifica se o seu serviço de lançamento ainda funciona, os telefones não estão mais tocando (a menos que você queira telefonar), etc. Quando você volta a uma operação estável conhecida, começa a ativar e verificar seus recursos recém-implantados.

Agora, sua resposta: como você gostaria de trabalhar em uma equipe onde estar de plantão é praticamente um acéfalo e nossos usuários nos amam porque nossos sites e serviços são estáveis?

Essa é a equipe em que quero trabalhar.

Você pode parar de ler aqui, se quiser.

Colocar tudo por trás de um interruptor de recurso parece que pode levar ao código de espaguete em qualquer lugar. Se você usa a IoC e pode selecionar entre vNow / vNext / vPrevious, tudo se resume a manter sua configuração. Sim, mais check-ins, sim mais classes (componentV1, componentV2, componentV3, etc.), mas você realmente tem um sistema mais estável? Quão? vNext é instável? Volte para o vNow com sua torre de controle. Já faz uma semana e o vNow tem um bug sutil? A mesma coisa - volte ao vPrevious com a mesma facilidade.

Sem problemas, sem preocupações, sem sono perdido, sem estresse.

Este não é um sonho. Eu costumava trabalhar lá. Gostaria de poder vender isso para minha equipe atual.

Um ambiente de desenvolvimento de alta velocidade bem-sucedido geralmente depende de um sistema automatizado bastante rigoroso, envolvendo verificações de qualidade com detecção e rejeição de alterações defeituosas que causam regressões.

As alternâncias de recursos oferecem a capacidade de confirmar mesmo alterações não testadas em andamento, sem ser rejeitadas por causar regressões no ramo de integração. O que constitui um incentivo muito bom para introduzir o recurso alterna muito cedo na vida do recurso.

Uma das desvantagens de desviar-se do IC verdadeiro e mover o desenvolvimento de recursos nas ramificações de recursos é a falta desse incentivo. A adição do recurso alterna posteriormente, ao mesclar o ramo do recurso no ramo de integração normalmente é mais difícil, como qualquer integração tardia.

Os desenvolvedores (e geralmente os gerentes de desenvolvimento) geralmente procuram dois resultados associados à estrutura: facilidade de gerenciamento e velocidade de implantação. Você deseja enviar o código mais rápido e mais fácil.

Forneça evidências de que a abordagem funciona; tente criar um pequeno POC usando sinalizadores de recursos em relação à maneira antiga. Os estudos de caso são menos importantes para pessoas táticas (desenvolvedores \ engenheiros) do que para pessoas estratégicas (gerência intermediária \ designers de produtos).

A lógica de alternar entre recursos não é algo que os desenvolvedores decidem. Isso é algo para os proprietários de produtos se importarem. Os desenvolvedores permitem essa mudança da maneira mais sustentável e segura. Eu critico esta mesma questão.