Como a Entrega Contínua pode funcionar na prática?

A entrega contínua parece boa, mas meus anos de experiência em desenvolvimento de software sugerem que, na prática, ela não funciona.

(Editar: para deixar claro, eu sempre tenho muitos testes sendo executados automaticamente. Minha pergunta é sobre como obter a confiança necessária para entregar cada check-in, que eu entendo ser a forma completa do CD. A alternativa não são os ciclos de um ano São iterações toda semana (que alguns ainda consideram CD se feitas corretamente), duas semanas ou mês; incluindo um controle de qualidade antiquado no final de cada um, complementando os testes automatizados.)

• A cobertura total do teste é impossível. Você precisa dedicar muito tempo - e tempo é dinheiro - para cada pequena coisa. Isso é valioso, mas o tempo pode ser gasto contribuindo para a qualidade de outras maneiras.
• Algumas coisas são difíceis de testar automaticamente. Por exemplo, GUI. Mesmo o Selenium não informa se a sua GUI é instável. É difícil testar o acesso ao banco de dados sem equipamentos volumosos, e mesmo isso não cobre casos estranhos de esquina no armazenamento de dados. Da mesma forma segurança e muitas outras coisas. Somente o código da camada de negócios é efetivamente testável por unidade.
• Mesmo na camada de negócios, a maioria dos códigos não possui funções simples cujos argumentos e valores de retorno podem ser facilmente isolados para fins de teste. Você pode gastar muito tempo criando objetos simulados, que podem não corresponder às implementações reais.
• Os testes de integração / funcionais complementam os testes de unidade, mas demoram muito tempo para serem executados porque geralmente envolvem a reinicialização de todo o sistema em cada teste. (Se você não reinicializar, o ambiente de teste será inconsistente.)
• A refatoração ou qualquer outra alteração quebra muitos testes. Você gasta muito tempo consertando-os. Se é uma questão de validar alterações significativas nas especificações, tudo bem, mas geralmente os testes são interrompidos devido a detalhes de implementação de baixo nível sem sentido, e não a coisas que realmente fornecem informações importantes. Freqüentemente, o aprimoramento é voltado para o retrabalho interno do teste, não para realmente verificar a funcionalidade que está sendo testada.
• Os relatórios de campo sobre bugs não podem ser facilmente combinados com a micro-versão precisa do código.

meus anos de experiência em desenvolvimento de software sugerem que, na prática, não pode funcionar.

Tentaste? Dave e eu escrevemos o livro com base em muitos anos de experiência coletiva, tanto de nós mesmos como de outras pessoas seniores da ThoughtWorks, realmente fazendo as coisas que discutimos. Nada no livro é especulativo. Tudo o que discutimos foi testado e testado, mesmo em grandes projetos distribuídos. Mas não sugerimos que você aceite isso com fé. Claro que você deve tentar e escreva o que acha que funciona e o que não funciona, incluindo o contexto relevante, para que outros possam aprender com suas experiências.

Entrega contínua tem um grande foco em testes automatizados. Gastamos cerca de 1/3 do livro falando sobre isso. Fazemos isso porque a alternativa - teste manual - é cara e propensa a erros e, na verdade, não é uma ótima maneira de criar software de alta qualidade (como Deming disse: "Cesse a dependência da inspeção em massa para obter qualidade. Melhore o processo e melhore a qualidade"). o produto em primeiro lugar ")

A cobertura total do teste é impossível. Você precisa dedicar muito tempo - e tempo é dinheiro - para cada pequena coisa. Isso é valioso, mas o tempo pode ser gasto contribuindo para a qualidade de outras maneiras.

É claro que a cobertura total do teste é impossível, mas qual é a alternativa: zero cobertura do teste? Há uma troca. Em algum lugar no meio está a resposta correta para o seu projeto. Concluímos que, em geral, você deve gastar cerca de 50% do seu tempo criando ou mantendo testes automatizados. Isso pode parecer caro até você considerar o custo de testes manuais abrangentes e corrigir os erros que surgem para os usuários.

Algumas coisas são difíceis de testar automaticamente. Por exemplo, GUI. Mesmo o Selenium não informa se a sua GUI é instável.

Claro. Confira o quadrante de teste de Brian Marick. Você ainda precisa executar testes exploratórios e testes de usabilidade manualmente. Mas é para isso que você deve usar seus seres humanos caros e valiosos - não para testes de regressão. A chave é que você precisa implantar um pipeline de implantação para que você só se preocupe em executar valiosas validações manuais em compilações que passaram por um conjunto abrangente de testes automatizados. Assim, você reduz a quantia gasta em testes manuais e o número de bugs que chegam a testes ou produção manuais (quando são muito caros de consertar). O teste automatizado feito da maneira certa é muito mais barato durante o ciclo de vida do produto, mas é claro que é um gasto de capital que se amortiza com o tempo.

É difícil testar o acesso ao banco de dados sem equipamentos volumosos, e mesmo isso não cobre casos estranhos de esquina no armazenamento de dados. Da mesma forma segurança e muitas outras coisas. Somente o código da camada de negócios é efetivamente testável por unidade.

O acesso ao banco de dados é testado implicitamente pelos testes de aceitação funcional baseados em cenários de ponta a ponta. A segurança exigirá uma combinação de teste automatizado e manual - teste de penetração automatizado e análise estática para encontrar (por exemplo) excedentes de buffer.

Mesmo na camada de negócios, a maioria dos códigos não possui funções simples cujos argumentos e valores de retorno podem ser facilmente isolados para fins de teste. Você pode gastar muito tempo criando objetos simulados, que podem não corresponder às implementações reais.

É claro que os testes automatizados são caros se você criar seu software e seus testes mal. Eu recomendo verificar o livro "crescente software orientado a objetos, guiado por testes" para entender como fazê-lo corretamente, para que seus testes e código sejam mantidos ao longo do tempo.

Os testes de integração / funcionais complementam os testes de unidade, mas demoram muito tempo para serem executados porque geralmente envolvem a reinicialização de todo o sistema em cada teste. (Se você não reinicializar, o ambiente de teste será inconsistente.)

Um dos produtos em que eu trabalhava tem um conjunto de 3.500 testes de aceitação de ponta a ponta que levam 18 horas para serem executados. Executamos em paralelo em uma grade de 70 caixas e obtemos feedback em 45m. Ainda mais do que o ideal, é por isso que o executamos como o segundo estágio no pipeline após a execução dos testes de unidade em alguns minutos, para não desperdiçarmos nossos recursos em uma construção da qual não temos um nível básico de confiança em.

A refatoração ou qualquer outra alteração quebra muitos testes. Você gasta muito tempo consertando-os. Se é uma questão de validar alterações significativas nas especificações, tudo bem, mas geralmente os testes são interrompidos devido a detalhes de implementação de baixo nível sem sentido, e não a coisas que realmente fornecem informações importantes. Freqüentemente, o aprimoramento é voltado para o retrabalho interno do teste, não para realmente verificar a funcionalidade que está sendo testada.

Se o seu código e testes estiverem bem encapsulados e fracamente acoplados, a refatoração não interromperá muitos testes. Descrevemos em nosso livro como fazer a mesma coisa também para testes funcionais. Se seus testes de aceitação forem interrompidos, isso significa que você está perdendo um ou mais testes de unidade; portanto, parte do CD envolve melhorar constantemente sua cobertura de testes para tentar encontrar erros no início do processo de entrega, onde os testes são mais detalhados e os os erros são mais baratos de corrigir.

Os relatórios de campo sobre bugs não podem ser facilmente combinados com a micro-versão precisa do código.

Se você estiver testando e lançando com mais frequência (parte do ponto do CD), é relativamente simples identificar a alteração que causou o bug. O objetivo principal do CD é otimizar o ciclo de feedback para que você possa identificar os erros o mais rápido possível após o check-in no controle de versão - e de fato, preferencialmente antes do check-in (é por isso que executamos os testes de construção e unidade antes do check-in).

Primeiro, o CD precisa de um grande ajuste mental - você precisa admitir que, às vezes, as coisas vão dar errado, não importa o que você faça. No final do dia, você não pode provar um negativo.

Depois de superar isso, você percebe que precisa de ferramentas e procedimentos para: a) capturar esses erros muito rapidamente eb) reverter ou implantar a atualização com muita eficiência. Além disso, se você está realmente bebendo o coquetel de CD, está realmente entregando muitas pequenas alterações pontuais que são fáceis de reverter e não devem ser capazes de introduzir bugs importantes em todo o aplicativo. Até os caras que realmente praticam CD estão lidando com grandes trocas de maneira mais tradicional.

Todo sistema tem riscos, e todo risco tem custos potenciais. Se o custo de um pequeno risco, do tipo que pode levar meses ou anos para ser encontrado em extensos testes e controle de qualidade, for alto o suficiente (o software em seu marcapasso cardíaco), você não envia sem um longo período de testes de um liberação congelada. Se o custo da falha for pequeno o suficiente, talvez você envie continuamente com zero teste (a página do Facebook do seu gato).

A cobertura total do teste é impossível. Você precisa dedicar muito tempo - e tempo é dinheiro - para cada pequena coisa. Isso é valioso, mas o tempo pode ser gasto contribuindo para a qualidade de outras maneiras.

Você não precisa de 100% de cobertura, precisa ter confiança suficiente em seu sistema, pois as alterações em um único local não afetarão as coisas que você provou anteriormente.

Algumas coisas são difíceis de testar automaticamente. Por exemplo, GUI. Mesmo o Selenium não
informa se a sua GUI é instável. É difícil testar o acesso ao banco de dados sem equipamentos volumosos, e mesmo isso não cobre casos estranhos de esquina no armazenamento de dados.

O acesso ao banco de dados é trivial de se escrever. Você não precisa de muitos testes na camada de dados, pois está apenas obtendo e configurando dados. O mais importante é garantir que, quando falhar, reverta e registre o problema para que você possa corrigi-lo.

Da mesma forma segurança e muitas outras coisas. Somente o código da camada de negócios é efetivamente testável por unidade. Mesmo na camada de negócios, a maioria dos códigos não possui funções simples cujos argumentos e valores de retorno podem ser facilmente isolados para fins de teste.

Então, muitas de suas funções / classes são muito grandes. Eles devem ser escritos para serem testáveis.

Você pode gastar muito tempo criando objetos simulados, que podem não corresponder às implementações reais.

A E / S do objeto simulado deve corresponder ao esperado. O que acontece dentro dele sem importância.

Os testes de integração / funcionais complementam os testes de unidade, mas demoram muito tempo para serem executados porque geralmente envolvem a reinicialização de todo o sistema em cada teste. (Se você não reinicializar, o ambiente de teste será inconsistente.)

Estes não devem ser executados o tempo todo. Apenas conforme necessário.

A refatoração ou qualquer outra alteração quebra muitos testes. Você gasta muito tempo consertando-os. Se é uma questão de validar alterações significativas nas especificações, tudo bem, mas geralmente os testes são interrompidos devido a detalhes de implementação de baixo nível sem sentido, e não a coisas que realmente fornecem informações importantes. Freqüentemente, o aprimoramento é voltado para o retrabalho interno do teste, não para realmente verificar a funcionalidade que está sendo testada.

Então, seu código está muito acoplado e seus testes são mal escritos.

Os relatórios de campo sobre bugs não podem ser facilmente combinados com a micro-versão precisa do código.

Não tem certeza do que está chegando aqui? Se houver um erro, escreva um teste para mostrar sua existência e corrija-o.

Funciona bem para nós, mas nossos clientes são principalmente internos. Várias construções feitas durante o dia, construções quebradas não são toleradas, mecanismo de início na web usado para que os usuários obtenham a versão mais recente a cada lançamento. Uma coisa é que o CD faz muitos problemas desaparecerem. Sim, você tem preocupações de compatibilidade o tempo todo, no entanto, como você está implantando pequenas alterações a cada vez, é realmente fácil entender essas preocupações. O nível de estresse do CD é MUITO menor do que quando fizemos grandes atualizações e tivemos que esperar que tudo estivesse certo, pois haveria muito código a ser revisado em caso de quebra.

Para ser honesto, TODOS os softwares estão em entrega contínua! O mais importante é tirá-lo da porta! Faça com que seus usuários o usem e priorize as solicitações de recursos e a eliminação de erros depois disso.

"Artistas reais enviam"
- Steve Jobs.