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.