Qual é o ROI da integração contínua?

https://stackoverflow.com/questions/2523841

22-09-2019
|

Pergunta

Atualmente, nossa organização não pratica integração contínua.

Para que possamos colocar um servidor de CI em funcionamento, precisarei produzir um documento demonstrando o retorno do investimento.

Além da economia de custos encontrando e corrigindo bugs mais cedo, estou curioso sobre outros benefícios/economias que eu poderia manter neste documento.

Solução

Meu motivo número 1 para gostar do IC é que ele ajuda a impedir que os desenvolvedores verifiquem em código quebrado, o que às vezes pode prejudicar uma equipe inteira. Imagine se eu fizer um check-in significativo envolvendo algumas mudanças de esquema de banco de dados antes de sair para férias. Claro, tudo funciona bem na minha caixa de dev, mas esqueço de fazer o check-in do esquema DB alterações que podem ou não ser triviais. Bem, agora existem mudanças complexas se referindo a campos novos/alterados no banco de dados, mas ninguém que está no escritório no dia seguinte realmente tem esse novo esquema, então agora toda a equipe está baixa enquanto alguém olha para reproduzir o trabalho que você já fez e apenas esqueci de fazer o check -in.

E sim, usei um exemplo particularmente desagradável com mudanças de banco de dados, mas poderia ser qualquer coisa, realmente. Talvez um check-in parcial com algum código de e-mail que faça com que todos os seus desenvolvedores spam seus usuários finais reais? O que você disser...

Portanto, na minha opinião, evitar uma única dessas situações fará com que o ROI desse esforço seja pago muito rapidamente.

Outras dicas

Se você está conversando com um gerente de programa padrão, eles podem achar uma integração contínua um pouco difícil de entender em termos de ROI simples: não é imediatamente óbvio qual produto físico eles receberão em troca de um determinado investimento em dólares.

Veja como aprendi a explicar: "A integração contínua elimina classes inteiras de risco do seu projeto".

Gerenciamento de riscos é um problema real para os gerentes de programas que estão fora do ken normal de tipos de engenharia de software que gastam mais tempo escrevendo código do que se preocupar com a forma como os dólares são gastos. Parte do trabalho com esse tipo de pessoa de maneira eficaz é aprender a expressar o que sabemos ser uma coisa boa em termos que elas podem entender.

Aqui estão alguns dos riscos que eu falo em conversas como essas. Observe que, com gerentes de programas sensatos, já ganhei o argumento após o primeiro ponto:

Risco de integração: em um sistema de construção contínuo baseado em integração, questões de integração como "ele esqueceu de verificar um arquivo antes de voltar para casa para um longo fim de semana" tem muito menos probabilidade de fazer . Economia para o projeto, evitando um desses incidentes = número de pessoas na equipe (menos uma devido ao vilão que esqueceu de fazer o check -in) * 8 horas por dia de trabalho * Taxa horária por engenheiro. Por aqui, isso equivale a milhares de dólares que não serão cobrados pelo projeto. ROI WIN!
Risco de regressão: com um conjunto de testes de unidade / teste automático que é executado após cada compilação, você reduz o risco de que uma alteração no código quebre algo que usa para funcionar. Isso é muito mais vago e menos seguro. No entanto, você está fornecendo pelo menos uma estrutura em que alguns dos testes humanos mais chatos e demorados (ou seja, caros) são substituídos por automação.
Risco tecnológico: a integração contínua também oferece a oportunidade de experimentar novos componentes de tecnologia. Por exemplo, descobrimos recentemente que a atualização 18 do Java 1.6 estava colidindo no algoritmo de coleta de lixo durante uma implantação em um site remoto. Devido à integração contínua, tínhamos muita confiança de que o retorno da atualização 17 teve uma alta probabilidade de trabalhar onde a atualização 18 não. Esse tipo de coisa é muito mais difícil de frase em termos de valor em dinheiro, mas você ainda pode usar o argumento de risco: certa falha do projeto = ruim. Downgrade gracioso = muito melhor.

O CI auxilia na descoberta de problemas. Meça a quantidade de tempo atualmente necessária para descobrir construções quebradas ou grandes bugs no código. Multiplique isso pelo custo da empresa para cada desenvolvedor usando esse código durante esse período. Multiplique isso pelo número de vezes que ocorrem quebras durante o ano.

Aí está o seu número.

Cada compilação bem -sucedida é um candidato de lançamento - para que você possa fornecer atualizações e correções de bugs muito mais rapidamente.

Se parte do seu processo de construção gerar um instalador, isso também permite um ciclo de implantação rápido.

A partir de Wikipedia:

Quando os testes de unidade falham ou surgem um bug, os desenvolvedores podem reverter a base de código de volta a um estado sem insetos, sem perder tempo depuração
Os desenvolvedores detectam e corrigem problemas de integração continuamente - evitando o caos de última hora nas datas de liberação (quando todo mundo tenta verificar suas versões ligeiramente incompatíveis).
Aviso precoce do código quebrado/incompatível
Aviso precoce de mudanças conflitantes
Teste de unidade imediata de todas as mudanças
Disponibilidade constante de uma construção "atual" para fins de teste, demonstração ou liberação
Feedback imediato aos desenvolvedores sobre a qualidade, funcionalidade ou impacto em todo o sistema do código que eles estão escrevendo
O check-in de código frequente empurra os desenvolvedores a criar código modular e menos complexo
As métricas geradas a partir de testes automatizados e IC (como métricas para cobertura de código, complexidade do código e recursos completos) focam os desenvolvedores no desenvolvimento de código funcional e de qualidade e ajudam a desenvolver impulso em uma equipe
Test-suite bem desenvolvido necessário para a melhor utilidade

Usamos o CI (duas compilações por dia) e ele nos economiza muito tempo para manter o código de trabalho disponível para teste e liberação.

Do ponto de vista do desenvolvedor, o IC pode ser intimidador quando o resultado automático de construção, enviado por e -mail a todo o mundo (desenvolvedores, gerentes de projeto etc. etc.), diz: "Erro ao carregar a construção da DLL de 'xyz.dll' falhou." E você é Sr. Xyz e eles sabem quem você é :)!

Aqui está o meu exemplo de minhas próprias experiências ...

Nosso sistema possui várias plataformas e configurações com mais de 70 engenheiros trabalhando na mesma base de código. Softemos de algo em torno de 60% de sucesso para as configurações menos usadas e 85% para os mais usados. Houve uma constante inundação de e-mails diariamente sobre erros de compilação ou outras falhas.

Fiz alguns cálculos difíceis e estimei que perdemos uma média de hora por dia por programador para construções ruins, o que totaliza quase 10 dias de trabalho todos os dias. Isso não considera os custos que ocorrem no tempo de iteração em que os programadores se recusam a sincronizar com o código mais recente, porque não sabem se é estável, isso nos custa ainda mais.

Depois de implantar um rack de servidores de construção gerenciados pela Team City, agora vemos uma taxa média de sucesso de 98% em todas as configurações, o erro médio de compilação permanece no sistema por minutos, não horas e a maioria de nossos engenheiros agora se sente confortável em ficar na revisão mais recente do código.

Em geral, eu diria que uma estimativa conservadora sobre nossa economia geral foi de cerca de 6 meses de tempo nos últimos três meses do projeto em comparação com os três meses anteriores à implantação do IC. Esse argumento nos ajudou a proteger recursos para expandir nossos servidores de construção e focar mais tempo de engenheiro em testes automatizados adicionais.

Nosso maior ganho é sempre ter uma construção noturna para o controle de qualidade. Sob nosso sistema antigo, cada produto, pelo menos uma vez por semana, descobriria às 2 da manhã que alguém havia verificado o código ruim. Isso não fez com que a construção noturna para o controle de qualidade testasse, o remédio era enviar um email para engenharia de liberação. Eles diagnosticariam o problema e entrariam em contato com um dev. Às vezes, demorava o meio -dia para que o controle de qualidade tivesse algo com o que trabalhar. Agora, além de ter um bom instalador todas as noites, na verdade a instalamos em VMs de todas as diferentes configurações suportadas a cada noite. Então, agora quando o controle de qualidade entra, eles podem começar a testar dentro de alguns minutos. Agora, quando você pensa na maneira antiga, o controle de qualidade entrou no instalador, acionou todas as VMs, instalou -o e depois começou a testar. Economizamos o controle de qualidade provavelmente 15 minutos por configuração para testar, por pessoa de controle de qualidade.

Existem servidores de IC gratuitos disponíveis e ferramentas de construção gratuitas como o NANT. Você pode implementá -lo em sua caixa de desenvolvimento para descobrir os benefícios.

Se você estiver usando o controle de origem e um sistema de rastreamento de insetos, imagino que seja consistentemente o primeiro a relatar bugs (em poucos minutos após cada check-in) será bastante atraente. Acrescente a isso a diminuição da sua própria taxa de bugs e você provavelmente terá uma venda.

O ROI é realmente uma capacidade de fornecer o que o cliente deseja. Obviamente, isso é muito subjetivo, mas quando implementado com o envolvimento do cliente final, você verá que os clientes começam a apreciar o que estão recebendo e, portanto, você tende a ver menos problemas durante a aceitação do usuário.

Isso economizaria custo? talvez não,
O projeto falharia durante o UAT? definitivamente não,
O projeto seria fechado no meio? - Alta possibilidade quando os clientes acham que isso não entregaria o resultado esperado.
Você receberia dados reais e em tempo real sobre o projeto - sim

Portanto, ajuda a falhar mais rapidamente, o que ajuda a mitigar os riscos mais cedo.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow