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


34

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.


13
Pode ser benéfico mesmo para uma equipe de um. Especialmente se você tiver um conjunto de testes de longa duração, é muito melhor obter automaticamente resultados de uma compilação e execução de teste durante a noite do que fazê-lo manualmente o tempo todo.
SK-logic

3
@Carnotaurus, clone local do repositório remoto do git se livra do tempo limite do controle de origem. Problemas de rede - para criar o produto? Agora, realmente ...

3
A luz vermelha do @Carnotaurus devido à qualidade ou infraestrutura dos dados é um código de testes frágeis . Veja também assim: gerir-the-manutenção-carga-de-unit-testes
k3b

1
Quanto mais um teste depende de aspectos externos, mais frágil é. Exemplo: se um teste for bem-sucedido apenas se o cliente XY estiver no banco de dados, o teste será frágil, a menos que a configuração do teste garanta que esse pré-requisito exista, inserindo os próprios dados, se necessário.
K3b

6
"Conclusão: por que criar produtos de trabalho quando conseguimos que outra pessoa nos pagasse por corrigi-lo, porque não é como se eles esperassem que o software funcionasse em primeiro lugar"? Pode não atender à definição legal, mas isso me parece uma fraude.
precisa

Respostas:


43

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.


1
@Carnotaurus, nesse caso, a luz vermelha também está sendo usada para erros transitórios. Parece uma limitação no mecanismo de CI que você está usando.

2
@Carnotaurus, na minha experiência, o trabalho realizado para documentar minuciosamente todos os aspectos de tudo, por exemplo, fazer um lançamento e, em seguida, fazer os lançamentos várias vezes, é maior do que capturar o fluxo de trabalho em um script form ou maven que pode ser executado por um robô qualquer número de vezes. O referido robô também trabalha em um ambiente de sala limpa, garantindo que as construções sejam reproduzíveis.

1
Observe que a falha que estou procurando não está falhando nos testes de unidade, mas que os programas reais que enviamos ainda podem criar. Não é mais tão importante quanto migramos para artefatos de maven em vez de compilar tudo para cada release, mas ainda é importante saber que a compilação é totalmente funcional. Também precisamos da parte de Implantação Contínua.

2
@Carnotaurus: Não estou falando de um sistema de alarme. Se os testes falharem, o patch não será integrado ao repositório principal, garantindo que, sempre que você fizer o checkout / clone, obtenha uma cópia de trabalho completa e possa começar a trabalhar imediatamente. Agora, concordo com você que os testes podem ser difíceis de escrever e manter ... mas trabalhei com e sem teste e vejo uma melhoria de qualidade definitiva com eles. Então a pergunta é: automatizada ou não? Na minha experiência, leva tanto tempo para testar manualmente quanto para escrever o script de automação (mas eu trabalho em uma grande corporação com ferramentas para isso).
Matthieu M.

5
" É muito trabalhoso capturar um punhado de bugs que a empresa seria pago pela correção como parte de um contrato de serviço ao cliente de qualquer maneira " - nesse caso, você tem incentivo econômico para NÃO produzir software com o menor número possível de bugs e nesse caso, tudo isso não se aplica a você.

33

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.


1
+1 - Eu tenho muito a acrescentar ao exposto acima - mas isso está muito próximo do motivo pelo qual eu gosto do CI ... não apenas pelo que ele faz, mas também pelo que exige que você faça para fazê-lo trabalho (esses requisitos são coisas que você realmente deveria fazer).
Murph

2
@murph: Sim, e traz poucas vantagens, como 1) saber o que o seu repositório criará, 2) compilação com um único clique, 3) poder lançar uma versão em um instante e muito mais
Binary Worrier

Portanto, é justo dizer que depende da complexidade do que será lançado, medido pelo número de etapas da implantação como sendo capaz de "testar" camadas separadas?
CarneyCode

1
@Carnotaurus: Desculpe companheiro, mas não sei se sei o que você está tentando dizer. O IC não tem nada a ver com o teste. Sim, você pode - e deve - executar testes de unidade como parte da compilação, mas eles não devem depender de nada que não esteja configurado como parte do teste. No entanto, o IC ajuda no teste. Um dos muitos benefícios do IC é que ele permite que uma equipe de controle de qualidade capte imediata e aparentemente novas alterações de código. CI = a capacidade de liberar imediatamente
Binary Worrier

1
@BinaryWorrier - Eu acho que o passo 1 é verificar no código;)

10

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.


Eu não havia considerado um cenário de plataforma cruzada. Se forem necessários compiladores diferentes para criar diferentes compilações, existe um forte argumento para o IC - faça um voto positivo.
CarneyCode 03/04

4

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.


Então, a duração do projeto (tamanho do projeto) é importante para você CI? Eu achei os alarmes falsos muito caros.
CarneyCode

Sim, você precisa ter tempo para pagar os custos de configuração e da curva de aprendizado. Em teoria, você deve aprender com o tempo a eliminar os alarmes falsos.
Stephen Bailey

Sim, isso é teoria
CarneyCode

Bem, não, é prática. Com o tempo, você anota quais testes são frágeis e quais não são, e não se preocupe muito se seus testes frágeis forem interrompidos, a menos que sejam interrompidos várias vezes seguidas. Você escreve testes mais robustos e isolados à medida que aprende e deixa a cobertura herdada aumentar com o tempo, em vez de fazer tudo de uma vez. Na prática, o IC não é uma bala de prata, é uma mudança de processo que leva tempo e acaba levando a menos softwares com erros.
Filodad

3

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.


Como eu disse, são os testes de unidade para cobrir o código herdado que apresenta um custo importante. Além disso, também não estamos falando de uma equipe de um homem ... Agradeço a atenção de Jenkins.
CarneyCode

1
Pelo que valeu a pena, obtive um benefício considerável ao executar um servidor de CI sem ter testes - apenas pela confiança em compilações limpas e pela disponibilidade de pacotes de implantação.
Murph

1

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.


Eu acho que é de onde eu também venho. Também é muito mais barato.
CarneyCode

O que você quer dizer com verificação neste caso? Se é automatizado, acontece com a maior frequência possível e ajuda a identificar desvios e omissões mentais, então sou a favor. :-)
William Payne

1

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).


Você quer dizer sem CI?
CarneyCode

1

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.


1
Substituir um teste de regressão manual por alguns testes automatizados da interface do usuário leva bastante tempo e habilidade. Em uma empresa, um sujeito escreveu cerca de 40% dos testes e deixou a empresa. Vários anos depois, os testes ainda não foram escritos. Aposto que isso é típico.
CarneyCode #

Não, não é típico.
quant_dev

Eu não tenho visto muito contra-evidência
CarneyCode

Se você escrever testes de integração / aceitação em DSL de linguagem natural, como o Gherkin, poderá traduzir facilmente o teste automatizado para manual. Portanto, não vejo isso como um problema.
Mike Cornell

@Carnotaurus - Eu acho que é típico. Eu já vi isso duas vezes também. Os testes automatizados da interface do usuário são difíceis.
Rocklan

1

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.


Eu gosto um pouco dos testes de interface do usuário no nível do sistema. Muitos dos testes se perdem em meio a testes de unidade de qualidade e cobertura questionáveis.
CarneyCode

A cobertura também é uma questão da psicologia humana; temos uma tendência inata de escrever testes para os casos em que já pensamos. É por esse motivo que, para serem certificados com um alto nível de SIL, os testes de unidade precisam ser escritos por uma equipe separada daquela que desenvolveu o sistema em teste e, mesmo assim, há muitos casos e situações que são óbvios para todos . Em retrospecto. É necessária uma verificação rigorosa da cobertura do código; mas extraordinariamente difícil e caro.
William Payne

... Por isso, o benefício que você começa por atirar o lixo mais desagradável que você pode encontrar para o sistema no nível superior e ver o que acontece ... :-)
William Payne

1
+1 - Concordo totalmente. Algumas partes de um sistema simplesmente não podem ser testadas por unidade (isto é, as bordas, como no banco de dados). Claro que você pode zombar do banco de dados, mas isso deixa o código que fala com o banco de dados não testado. Em algum momento, você precisa escrever alguns testes do mundo real que integram seus sistemas e conversam com outros sistemas. Quando você faz isso, sempre encontra erros que perdeu no aconchegante mundo limpo do teste de unidade e na estrutura de zombaria (o LINQ to SQL vem à mente).

Na verdade, eu descobri recentemente uma tomada interessante em testes de fuzz que pudesse redimir o teste de unidade: jester.sourceforge.net
William Payne

0

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.



0

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.
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.