Eu tenho usado o fantoche para implantação de infraestrutura, e a maior parte do trabalho que faço é com empresas da Web 2.0 que estão muito envolvidas no desenvolvimento orientado a testes para seus aplicativos 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? Qual a profundidade dos seus testes?
deployment
testing
automated-testing
Jon Topper
fonte
fonte
Eu acho que Joseph Kern está no caminho certo com as ferramentas de monitoramento. O ciclo TDD típico é: escreva um novo teste que falhe e 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ê deseja obter um 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, é possível que você não "monitore" sua versão do sistema operacional), mas não há motivo para não combinar e combinar conforme apropriado.
fonte
Embora eu ainda não tenha sido capaz de fazer TDD com manifestos Puppet, temos um ciclo muito bom para impedir que as alterações entrem em produção sem teste. Temos dois mestres de marionetes configurados, um é o mestre de marionetes de produção e o outro é o mestre de marionetes de desenvolvimento. Usamos os "ambientes" do Puppet para configurar o seguinte:
Nossos desenvolvedores de aplicativos trabalham em máquinas virtuais que obtêm suas configurações do Puppet no ambiente de "teste" do Puppetmaster de desenvolvimento. Quando estamos desenvolvendo manifestos do Puppet, geralmente configuramos uma VM para servir como cliente de teste durante o processo de desenvolvimento e apontamos para o nosso ambiente de desenvolvimento pessoal. Quando estamos satisfeitos com nossos manifestos, os enviamos para o ambiente de teste onde os desenvolvedores de aplicativos recebem as alterações em suas VMs - eles geralmente reclamam em voz alta quando algo quebra :-)
Em um subconjunto representativo de nossas máquinas de produção, há um segundo fantoche em execução no modo noop e apontado para o ambiente de teste. Usamos isso para detectar possíveis problemas com os manifestos antes que eles sejam levados à produção.
Depois que as alterações são aprovadas, ou seja, elas não quebram as máquinas do desenvolvedor de aplicativos e não produzem resultados indesejáveis nos registros do processo fantoche "noop" das máquinas de produção, colocamos os novos manifestos em produção. Temos um mecanismo de reversão em vigor para que possamos reverter para uma versão anterior.
fonte
Eu trabalhei em um ambiente que estava em processo de migração para um modelo de operações TDD. Para algumas coisas, como monitorar scripts, isso funcionou muito bem. Usamos o buildbot para configurar o ambiente de teste e executar os testes. Nesse caso, você aborda o TDD da perspectiva do "Código herdado". No TDD, "Código Legado" é um código existente que não possui testes. Para que os primeiros testes não falhem, eles definem a operação correta (ou esperada).
Para muitos trabalhos de configuração, a primeira etapa é testar se a configuração pode ser analisada pelo serviço. Muitos serviços fornecem algumas facilidades para fazer exatamente isso. O Nagios possui o modo de comprovação, o cfagent não possui ação, apache, sudo, bind e muitos outros possuem recursos semelhantes. Isso é basicamente uma execução de cotão para as configurações.
Um exemplo seria se você usar o apache e separar arquivos de configuração para partes diferentes, poderá testá-las e apenas usar um arquivo httpd.conf diferente para envolvê-las para execução em sua máquina de teste. Em seguida, você pode testar se o servidor da web na máquina de teste fornece os resultados corretos lá.
A cada passo no caminho, você segue o mesmo padrão básico. Faça um teste, faça o teste passar, refatorar o trabalho que você fez. Como mencionado acima, ao seguir esse caminho, os testes nem sempre podem falhar da maneira aceita pelo TDD.
Rik
fonte
Acredito que os seguintes links possam ser de interesse
cucumber-nagios - projeto que permite transformar seu pacote Cucumber no plug-in Nagios e que vem com definições de etapas para SSH, DNS, Ping, AMQP e tipos genéricos de tarefas "execute command"
http://auxesis.github.com/cucumber- nagios /
http://www.slideshare.net/auxesis/behaviour-driven-monitoring-with-cucumbernagios-2444224
http://agilesysadmin.net/cucumber-nagios
Há também algum esforço no lado das coisas Puppet / Python http://www.devco.net/archives/2010/03/27/infrastructure_testing_with_mcollective_and_cucumber.php
fonte