Ho usato le marionette per la distribuzione dell'infrastruttura e la maggior parte del lavoro che faccio è con aziende Web 2.0 che sono fortemente impegnate nello sviluppo guidato dai test per la loro applicazione web. Qualcuno qui utilizza un approccio test-driven per sviluppare le proprie configurazioni di server? Quali strumenti usi per fare questo? Quanto è profondo il test?
Risposte:
Non penso che potresti usare lo sviluppo test-driven . Ma potresti sicuramente provare i test unitari su nuovi server.
Fondamentalmente è necessario distribuire i server, avviare i servizi in una modalità di test e quindi eseguire i test da un altro server (o serie di server) rispetto ai servizi. Quindi finalmente li mettono in produzione.
Forse usando gli script Python per connettersi a database, pagine Web e servizi SSH. E quindi restituire un PASS / FAIL. Sarebbe un buon inizio per te.
Oppure potresti semplicemente arrotolarlo in una soluzione di monitoraggio, come Zenoss, Nagios o Munin. Quindi è possibile verificare, durante la distribuzione; E monitorare durante la produzione.
Penso che Joseph Kern sia sulla buona strada con gli strumenti di monitoraggio. Il tipico ciclo TDD è: scrivere un nuovo test che fallisce, quindi aggiornare il sistema in modo che tutti i test esistenti passino. Sarebbe facile adattarsi a Nagios: aggiungere il controllo non riuscito, configurare il server, rieseguire tutti i controlli. Vieni a pensarci bene, a volte ho fatto esattamente questo.
Se vuoi diventare veramente hard-core, assicurati di scrivere degli script per controllare ogni aspetto rilevante delle configurazioni del server. Un sistema di monitoraggio come Nagios potrebbe non essere pertinente per alcuni di essi (ad esempio, potresti non "monitorare" la versione del tuo sistema operativo), ma non c'è motivo per cui non sia possibile combinare e abbinare nel modo appropriato.
Anche se non sono stato ancora in grado di fare TDD con i manifest di Puppet, abbiamo un ciclo abbastanza buono per impedire che i cambiamenti entrino in produzione senza test. Abbiamo creato due burattinai, uno è il nostro burattinaio di produzione e l'altro è il nostro burattinaio di sviluppo. Usiamo gli "ambienti" di Puppet per impostare quanto segue:
I nostri sviluppatori di applicazioni lavorano su macchine virtuali che ottengono le configurazioni Puppet dall'ambiente di "testing" di Puppetmaster. Quando sviluppiamo manifesti Puppet, di solito configuriamo una VM per servire come client di test durante il processo di sviluppo e indirizzarlo al nostro ambiente di sviluppo personale. Una volta che siamo soddisfatti dei nostri manifest, li spingiamo nell'ambiente di test in cui gli sviluppatori dell'applicazione riceveranno le modifiche sulle loro macchine virtuali - di solito si lamentano rumorosamente quando qualcosa si rompe :-)
Su un sottoinsieme rappresentativo delle nostre macchine di produzione, c'è un secondo pupazzo in esecuzione in modalità noop e puntato sull'ambiente di test. Usiamo questo per cogliere potenziali problemi con i manifest prima che vengano spinti alla produzione.
Una volta che le modifiche sono passate, cioè non danneggiano le macchine dello sviluppatore dell'applicazione e non producono output indesiderabili nei registri del processo fantoccio "noop" delle macchine di produzione, spingiamo i nuovi manifesti in produzione. Abbiamo un meccanismo di rollback in atto in modo da poter tornare a una versione precedente.
Ho lavorato in un ambiente che stava migrando verso un modello operativo TDD. Per alcune cose come il monitoraggio degli script ha funzionato molto bene. Abbiamo usato buildbot per configurare l'ambiente di test ed eseguire i test. In questo caso ti avvicini a TDD dal punto di vista di "Legacy Code". Nel TDD "Codice legacy" è un codice esistente che non ha test. Quindi i primi test non falliscono, definiscono il funzionamento corretto (o previsto).
Per molti lavori di configurazione, il primo passo è verificare se la configurazione può essere analizzata dal servizio. Molti servizi forniscono alcune strutture per fare proprio questo. Nagios ha la modalità preflight, cfagent non ha act, apache, sudo, bind e molti altri hanno strutture simili. Questo è fondamentalmente un ciclo di lanugine per le configurazioni.
Un esempio potrebbe essere se usi apache e file di configurazione separati per parti diverse, puoi testare le parti e semplicemente usare un file httpd.conf diverso per avvolgerle per l'esecuzione sul tuo computer di prova. Quindi è possibile verificare che il server web sulla macchina di prova fornisca lì i risultati corretti.
Ogni passo lungo il modo in cui segui lo stesso schema di base. Scrivi un test, fai passare il test, rifatti il lavoro che hai svolto. Come accennato in precedenza, quando si segue questo percorso, i test potrebbero non fallire sempre nel modo TDD accettato.
Rik
Credo che i seguenti link possano essere di interesse
cucumber-nagios - progetto che ti consente di trasformare la tua suite Cucumber in plugin Nagios e che include definizioni di passi per tipi di attività SSH, DNS, Ping, AMQP e generici "esegui comando"
http://auxesis.github.com/cucumber- nagios /
http://www.slideshare.net/auxesis/behaviour-driven-monitoring-with-cucumbernagios-2444224
http://agilesysadmin.net/cucumber-nagios
Ci sono anche alcuni sforzi sul lato delle marionette / Python http://www.devco.net/archives/2010/03/27/infrastructure_testing_with_mcollective_and_cucumber.php