Quantos desenvolvedores antes da integração contínua se tornar eficaz para nós?

Há uma sobrecarga associada à integração contínua, por exemplo, configuração, treinamento, atividades de conscientização, interrupção para corrigir "bugs" que acabam sendo problemas de dados, separação forçada de estilos de programação de preocupações etc.

Em que momento a integração contínua se paga?

EDIT: Estas foram as minhas conclusões

A configuração foi CruiseControl.Net com Nant, lendo VSS ou TFS.

Aqui estão algumas razões para a falha, que nada têm a ver com a instalação:

Custo da investigação : o tempo gasto investigando se um sinal vermelho é devido a uma inconsistência lógica genuína no código, na qualidade dos dados ou em outra fonte, como um problema de infraestrutura (por exemplo, um problema de rede, uma leitura de tempo limite do controle de origem, servidor de terceiros) está em baixo, etc., etc.)

Custos políticos sobre a infraestrutura : considerei executar uma verificação de "infraestrutura" para cada método na execução de teste. Eu não tinha solução para o tempo limite, exceto para substituir o servidor de compilação. A burocracia ficou no caminho e não houve substituição do servidor.

Custo da correção de testes de unidade : uma luz vermelha devido a um problema de qualidade dos dados pode ser um indicador de um teste de unidade mal escrito. Portanto, os testes de unidade dependentes de dados foram reescritos para reduzir a probabilidade de um sinal vermelho devido a dados incorretos. Em muitos casos, os dados necessários foram inseridos no ambiente de teste para poder executar com precisão seus testes de unidade. Faz sentido dizer que, ao tornar os dados mais robustos, o teste se torna mais robusto se depender desses dados. Claro, isso funcionou bem!

Custo da cobertura, ou seja, escrever testes de unidade para código já existente : Houve um problema de cobertura de teste de unidade. Havia milhares de métodos que não tinham testes de unidade. Portanto, uma quantidade considerável de dias-homem seria necessária para criá-los. Como isso seria muito difícil para fornecer um caso de negócios, foi decidido que os testes de unidade seriam usados ​​para qualquer novo método público daqui para frente. Aqueles que não tiveram um teste de unidade foram denominados 'potencialmente infravermelho'. Um ponto interessante aqui é que os métodos estáticos eram um ponto discutível de como seria possível determinar exclusivamente como um método estático específico falhou.

Custo de lançamentos sob medida : os scripts Nant só vão tão longe. Eles não são tão úteis para, por exemplo, compilações dependentes do CMS para EPiServer, CMS ou qualquer implantação de banco de dados orientada à interface do usuário.

Esses são os tipos de problemas que ocorreram no servidor de compilação para execuções de teste por hora e compilações de controle de qualidade durante a noite. Eu entendo que isso não é necessário, pois um mestre de compilação pode executar essas tarefas manualmente no momento do lançamento, especialmente com uma banda de um homem e uma compilação pequena. Portanto, compilações de etapa única não justificaram o uso de IC na minha experiência. E as compilações de etapas múltiplas mais complexas? Isso pode ser difícil de criar, especialmente sem um script Nant. Assim, mesmo tendo criado um, eles não tiveram mais sucesso. Os custos de correção dos problemas da luz vermelha superaram os benefícios. Eventualmente, os desenvolvedores perderam o interesse e questionaram a validade do sinal vermelho.

Depois de fazer uma tentativa justa, acredito que o IC é caro e há muito trabalho por aí, em vez de apenas fazer o trabalho. É mais econômico empregar desenvolvedores experientes que não estragam grandes projetos do que introduzir e manter um sistema de alarme.

Este é o caso, mesmo que esses desenvolvedores saiam. Não importa se um bom desenvolvedor sai porque os processos que ele segue garantiriam que ele escrevesse especificações de requisitos, especificações de design, cumprisse as diretrizes de codificação e comentasse seu código para que fosse legível. Tudo isso é revisto. Se isso não estiver acontecendo, o líder da equipe não fará o trabalho, que deve ser escolhido pelo gerente e assim por diante.

Para que a CI funcione, não basta escrever testes de unidade, tentar manter a cobertura total e garantir uma infraestrutura de trabalho para sistemas consideráveis.

A linha inferior: Pode-se questionar se a correção de tantos bugs antes do lançamento é desejável mesmo do ponto de vista comercial. O IC envolve muito trabalho para capturar alguns bugs que o cliente pode identificar no UAT ou a empresa pode ser paga pela correção como parte de um contrato de serviço ao cliente quando o período de garantia expirar de qualquer maneira.

A instalação de um mecanismo de CI é semelhante à instalação de um alarme de incêndio em uma casa.

Na minha opinião, os benefícios não se correlacionam com muitos desenvolvedores, mas com uma grande base de código. O mecanismo de CI executa ativamente todo o trabalho chato que você não deseja fazer e o faz sempre.

Se você quebrar um módulo remoto que não tocou por muito tempo, você será avisado imediatamente. Não apenas em termos de compilação, mas também funcionalmente, se você configurou testes de unidade.

Observe também que, se você permitir que o mecanismo de CI faça todo o trabalho chato, incluindo a instalação de instaladores etc., não será necessário fazê-lo manualmente. Você pode apenas verificar sua fonte e aguardar que o produto final seja construído no local padrão. (EDIT: O mecanismo de CI também funciona em um ambiente bem definido, evitando configurações específicas do desenvolvedor, garantindo a reprodutibilidade)

Isso também faz parte da garantia da qualidade.

Edição: Depois de escrever o acima, tive experiência com a ferramenta de compilação Maven para Java. Essencialmente, isso nos permite manter a configuração completa do IC dentro do projeto (com pom.xml), tornando muito mais simples manter a instalação do CI e / ou migrar para outro mecanismo de CI.

Não é quantos desenvolvedores, mas quantas etapas são necessárias para chegar de 1 a n (inclusive), onde 1 & n estão ...

1: Verificando o código
E
n: tendo pacotes instaláveis ​​\ implantáveis

Se n <2, você talvez não precise de IC
, caso contrário, precisará de IC

Atualização
Ao ler suas descobertas, só posso concluir que você abordou a CI pela direção errada e pelos motivos errados.

Pode valer a pena o esforço, mesmo para uma equipe de um. Isso é especialmente verdade quando você está desenvolvendo código de plataforma cruzada e precisa garantir que suas alterações funcionem nas duas plataformas. Por exemplo, o compilador C ++ da Microsoft é mais aceito do que o GCC; portanto, se você desenvolve no Windows, mas também precisa oferecer suporte ao Linux, um sistema de CI informa quando a quebra de sua compilação no Linux é uma grande ajuda.

Alguns sistemas de CI são muito fáceis de configurar, portanto, a sobrecarga não é realmente tão grande. Tente Jenkins ou Hudson, por exemplo.

Como você diz, há um custo adicional para configurá-lo e mantê-lo funcionando.

Mas a questão de onde está o ponto de equilíbrio não é uma função de quantas pessoas você tem em sua equipe, mas uma função da duração do seu projeto.

Dito isso, há uma parte do custo de configuração que você pode usar em todos os seus projetos futuros; portanto, a longo prazo, o custo indireto pode chegar a zero.

Configurei o Jenkins esta semana para criar um pequeno projeto .NET no qual estou trabalhando. Eu o integrei ao meu controle de origem Git, para que ele desencadeasse uma compilação em cada commit. Integrei os testes de unidade na compilação. Integrei a análise estática na forma de violações do FxCop e StyleCop.

Agora, toda vez que eu faço check-in, ele faz check-out de todo o meu código, cria-o, incrementa o número da versão em todos os assemblies, testa-o, analisa-o em busca de violações do FxCop e StyleCop, arquiva o build e registra os resultados em vários gráficos para Tenho visibilidade ao longo do tempo dos resultados e violações dos testes.

Fazer isso do zero leva mais ou menos uma hora (talvez um dia com o Google, se você não tiver feito isso antes). Não custa nada, porque todas as ferramentas estão disponíveis gratuitamente.

Se, como e quando o projeto for construído, tenho uma infraestrutura de alta qualidade que crescerá com ele sem nenhum custo. Se ou quando novos desenvolvedores ingressarem no projeto, posso obter total visibilidade de seu trabalho e seu impacto no projeto sem nenhum custo.

Portanto, o único cenário em que posso ver que o IC não vale a pena é para um projeto que levará mais ou menos um dia e nunca mais será revisado, ou em um idioma em que não existem ferramentas gratuitas / existentes disponíveis e o custo para adquiri-las é desproporcional ao trabalho.

Se você pode verificar todos os aspectos do seu projeto após cada alteração, não precisa do IC.

Em todos os outros casos, é uma vitória líquida.

A sobrecarga é mínima. Eu diria que, para um homem, projetos seria útil. Quando você alcança dois, é inestimável.

Concordo que, para projetos individuais, se você tem uma "construção / verificação em uma etapa", pode ser que você esteja bem com a integração contínua, mas nesses casos você fez a maior parte do trabalho árduo para configurar o IC, então é melhor colocar em um sistema formal (CC, Hudson, TeamCity, etc).

A questão de quando a CI se paga por si mesma é difícil de responder em um novo projeto.

Em um projeto existente, é muito mais fácil ver. Se você encontrar um bug crítico na parte de desenvolvimento da cadeia de suprimentos, sabe que o problema existe o mais cedo possível. O custo para a correção agora é o mais baixo. Se esse problema existir em qualquer ambiente acima do desenvolvimento, seu custo será maior.

Agora, a gerência pode decidir lançar com um bug, mas isso é um risco comercial. Pelo menos agora, isso pode ser mitigado por meio da avaliação de riscos, em vez de telefonemas / pânico noturnos, que, se cobrados a uma taxa horária, acabam sendo muito caros.

Outra coisa a considerar em termos de custo. Como é o seu departamento de controle de qualidade? É teste manual? Se você aderir ao IC, poderá reduzir os custos gerais de controle de qualidade automatizando esses scripts na sua caixa de desenvolvimento. Você pode reduzir o número de pessoas de controle de qualidade que apóiam seu projeto, envolvendo-os na fase de IC.

O IC sempre vale sempre a pena: a sensação de segurança que você fornece permite que você trabalhe a uma taxa mais rápida do que seria possível de outra forma. O problema que você tem parece girar em torno de testes de unidade. Concordo que os testes de unidade são muito caros, mas também acho que (para muitas coisas) eles são a pior opção que temos. Pessoalmente, e para os tipos de sistemas em que costumo trabalhar, juro por testes no nível do sistema operando em uma combinação de casos patológicos do mundo real e (possivelmente sintéticos); É mais barato que os testes de unidade e entra nos cantos mais difíceis de alcançar do seu universo conceitual: "Unknown Unknowns", de Donald Rumsfeld.

Sempre use-o, independentemente do tamanho da equipe. Se é apenas você, por exemplo, quem sabe, você pode estar codificando no seu laptop na starbucks e continuar no seu sistema mais robusto em casa?

A sobrecarga realmente não é tão ruim assim.

1. Sim, basta começar a usar a integração contínua.

Não se trata de quantos desenvolvedores, mas de

uma. Quanto tempo você economiza usando a automação e com que frequência.

• Tempo economizado na construção após integrações, executando testes automatizados e criando configurações * frequência de check-in = porcentagem de tempo economizado.

b. Quantas versões / filiais / produtos você possui.

• Se você tiver um desenvolvedor trabalhando em duas filiais diferentes, o tempo economizado será dobrado, pois cada filial exigiria construção, teste e empacotamento.