Desenvolvimento orientado a teste para implementações de infraestrutura?

Question

Estou usando fantoches para a implantação de infra-estrutura, e a maior parte do trabalho que faço é com empresas da Web 2.0 que estão concentradas no desenvolvimento orientado a testes para seu aplicativo da web. Alguém aqui usa uma abordagem orientada a testes para desenvolver suas configurações de servidor? Quais ferramentas você usa para fazer isso? Quão profundo é o seu teste?

    

Answer 1

Eu não acho que você poderia usar desenvolvimento orientado a testes . Mas você certamente poderia tentar testar unidades em novos servidores.

Basicamente, você precisaria implantar servidores, iniciar os serviços em um modo de teste e executar testes de outro servidor (ou série de servidores) nos serviços. Então, finalmente, coloque-os em produção.

Talvez usando scripts python para se conectar a bancos de dados, páginas da Web e serviços ssh. E então retorne um PASSA / FALHA. Seria um bom começo para você.

Ou você pode simplesmente transformar isso em uma solução de monitoramento, como Zenoss, Nagios ou Munin. Então você pode testar, durante a implantação; E monitorar durante a produção.

    

Answer 2

Acho que Joseph Kern está no caminho certo com as ferramentas de monitoramento. O ciclo TDD típico é: grave um novo teste que falhe e, em seguida, atualize o sistema para que todos os testes existentes sejam aprovados. Isso seria fácil de se adaptar ao Nagios: adicione a verificação com falha, configure o servidor, execute novamente todas as verificações. Venha para pensar sobre isso, eu fiz exatamente isso às vezes.

Se você quiser ser realmente hard-core, certifique-se de escrever scripts para verificar todos os aspectos relevantes das configurações do servidor. Um sistema de monitoramento como o Nagios pode não ser relevante para alguns deles (por exemplo, você pode não "monitorar" sua versão do sistema operacional), mas não há motivo para que você não possa misturar e combinar conforme apropriado.

    

Answer 3

Ainda não consegui fazer o TDD com os manifestos do Puppet, mas temos um ciclo muito bom para evitar que as alterações entrem em produção sem testes. Temos dois maestros de marionetes, um é nosso mestre de marionetes de produção e o outro é nosso mestre de marionetes de desenvolvimento. Usamos os "ambientes" do Puppet para configurar o seguinte:

• ambientes de desenvolvimento (um para cada pessoa que trabalha nos manifestos do Puppet)
• ambiente de teste
• ambiente de produção

Nossos desenvolvedores de aplicativos fazem seu trabalho em máquinas virtuais que obtêm suas configurações de Puppet do ambiente de "teste" de desenvolvimento do Puppetmaster. Quando estamos desenvolvendo manifestos Puppet, geralmente configuramos uma VM para servir como um cliente de teste durante o processo de desenvolvimento e apontá-lo para o nosso ambiente de desenvolvimento pessoal. Uma vez que estamos felizes com nossos manifestos, nós os enviamos para o ambiente de teste, onde os desenvolvedores de aplicativos receberão as alterações em suas VMs - eles geralmente reclamam alto quando algo quebra: -)

Em um subconjunto representativo de nossas máquinas de produção, há um segundo puppetd rodando no modo noop e apontado para o ambiente de teste. Usamos isso para detectar possíveis problemas com os manifestos antes que eles sejam enviados para a produção.

Uma vez que as alterações tenham passado, ou seja, elas não quebram as máquinas do desenvolvedor de aplicativos e elas não produzem resultados indesejáveis nos logs do processo de puppetd "noop" das máquinas de produção, nós colocamos os novos manifestos em produção. Temos um mecanismo de reversão para que possamos reverter para uma versão anterior.

    

Answer 4

Eu trabalhei em um ambiente que estava em processo de migração para um modelo de operações TDD. Para algumas coisas, como o monitoramento de scripts, isso funcionou muito bem. Usamos o buildbot para configurar o ambiente de teste e executar os testes. Neste caso, você aborda o TDD da perspectiva do "Código Legado". Em TDD, "Código Legado" é um código existente que não possui testes. Assim, os primeiros testes não falham, eles definem a operação correta (ou esperada).

Para muitos trabalhos de configuração, o primeiro passo é testar se a configuração pode ser analisada pelo serviço. Muitos serviços fornecem algumas facilidades para fazer exatamente isso. Nagios tem modo preflight, cfagent não tem ato, apache, sudo, bind, e muitos outros têm facilidades similares. Isso é basicamente um fiapo para as configurações.

Um exemplo seria se você usa o apache e separa os arquivos de configuração para partes diferentes, você pode testar as partes também apenas usar um arquivo httpd.conf diferente para envolvê-las na sua máquina de teste. Então você pode testar se o servidor da máquina de teste fornece os resultados corretos.

A cada passo do caminho, você segue o mesmo padrão básico. Escreva um teste, faça o teste passar, refatorie o trabalho que você fez. Como mencionado acima, ao seguir esse caminho, os testes nem sempre podem falhar da maneira TDD aceita.

Rik

    

Answer 5

Acredito que os links a seguir possam ser de interesse

1. cucumber-nagios - projeto que permite transformar o seu pacote Pepino no plugin Nagios e que vem com definições de passos para SSH, DNS , Ping, AMQP e genérica "execute comando" tipos de tarefas de link
   link
   link

2. Há também algum esforço no lado Puppet / Python das coisas link