J'ai utilisé des marionnettes pour le déploiement de l'infrastructure, et la plupart du travail que je fais est avec des entreprises Web 2.0 qui sont fortement impliquées dans le développement piloté par les tests pour leur application Web. Est-ce que quelqu'un ici utilise une approche pilotée par les tests pour développer ses configurations de serveur? Quels outils utilisez-vous pour ce faire? Quelle est la profondeur de vos tests?
Réponses:
Je ne pense pas que vous puissiez utiliser le développement piloté par les tests . Mais vous pouvez certainement essayer les tests unitaires sur de nouveaux serveurs.
Fondamentalement, vous devez déployer des serveurs, démarrer les services en mode test, puis exécuter des tests à partir d'un autre serveur (ou d'une série de serveurs) par rapport aux services. Puis enfin les mettre en production.
Peut-être en utilisant des scripts python pour se connecter à des bases de données, des pages Web et des services ssh. Et puis retournez un PASS / FAIL. Ce serait un bon début pour vous.
Ou vous pouvez simplement regrouper cela dans une solution de surveillance, comme Zenoss, Nagios ou Munin. Ensuite, vous pouvez tester, pendant le déploiement; Et surveiller pendant la production.
Je pense que Joseph Kern est sur la bonne voie avec les outils de surveillance. Le cycle TDD typique est le suivant: écrire un nouveau test qui échoue, puis mettre à jour le système pour que tous les tests existants réussissent. Ce serait facile à adapter à Nagios: ajoutez la vérification qui échoue, configurez le serveur, relancez toutes les vérifications. À bien y penser, j'ai fait exactement cela parfois.
Si vous voulez devenir vraiment dur, vous devez vous assurer d'écrire des scripts pour vérifier tous les aspects pertinents des configurations de serveur. Un système de surveillance comme Nagios peut ne pas être pertinent pour certains d'entre eux (par exemple, vous ne pouvez pas «surveiller» la version de votre système d'exploitation), mais il n'y a aucune raison pour laquelle vous ne pouvez pas mélanger et assortir comme il convient.
Bien que je n'aie pas encore pu faire TDD avec les manifestes Puppet, nous avons un assez bon cycle pour empêcher les changements d'entrer en production sans test. Nous avons mis en place deux marionnettistes, l'un est notre marionnettiste de production et l'autre est notre marionnettiste de développement. Nous utilisons les "environnements" de Puppet pour configurer les éléments suivants:
Nos développeurs d'applications font leur travail sur des machines virtuelles qui obtiennent leurs configurations Puppet à partir de l'environnement de "test" de Puppetmaster. Lorsque nous développons des manifestes Puppet, nous configurons généralement une machine virtuelle pour servir de client de test pendant le processus de développement et la pointons vers notre environnement de développement personnel. Une fois que nous sommes satisfaits de nos manifestes, nous les poussons vers l'environnement de test où les développeurs d'applications obtiendront les modifications sur leurs machines virtuelles - ils se plaignent généralement fortement quand quelque chose se casse :-)
Sur un sous-ensemble représentatif de nos machines de production, il y a une deuxième marionnette fonctionnant en mode noop et pointant vers l'environnement de test. Nous l'utilisons pour détecter les problèmes potentiels avec les manifestes avant qu'ils ne soient mis en production.
Une fois que les changements sont passés, c'est-à-dire qu'ils ne cassent pas les machines du développeur d'applications et qu'ils ne produisent pas de sortie indésirable dans les journaux du processus fantoche "noop" des machines de production, nous poussons les nouveaux manifestes en production. Nous avons un mécanisme de restauration en place afin que nous puissions revenir à une version antérieure.
J'ai travaillé dans un environnement qui était en train de migrer vers un modèle d'opérations TDD. Pour certaines choses comme la surveillance des scripts, cela a très bien fonctionné. Nous avons utilisé buildbot pour configurer l'environnement de test et exécuter les tests. Dans ce cas, vous abordez TDD du point de vue du «Legacy Code». Dans TDD "Legacy Code" est un code existant qui n'a pas de tests. Ainsi, les premiers tests n'échouent pas, ils définissent un fonctionnement correct (ou attendu).
Pour de nombreux travaux de configuration, la première étape consiste à tester si la configuration peut être analysée par le service. De nombreux services offrent certaines installations pour ce faire. Nagios a un mode de contrôle en amont, cfagent n'a pas d'acte, apache, sudo, bind et beaucoup d'autres ont des fonctionnalités similaires. Il s'agit essentiellement d'une course à charpie pour les configurations.
Un exemple serait que si vous utilisez apache et des fichiers de configuration séparés pour différentes parties, vous pouvez également tester les parties en utilisant simplement un fichier httpd.conf différent pour les envelopper pour les exécuter sur votre machine de test. Ensuite, vous pouvez tester que le serveur Web sur la machine de test y donne les résultats corrects.
À chaque étape, vous suivez le même schéma de base. Écrivez un test, réussissez le test, refactorisez le travail que vous avez fait. Comme mentionné ci-dessus, lorsque vous suivez ce chemin, les tests peuvent ne pas toujours échouer de la manière TDD acceptée.
Rik
Je pense que les liens suivants pourraient être intéressants
cucumber-nagios - projet qui vous permet de transformer votre suite Cucumber en plugin Nagios et qui comprend des définitions d'étapes pour les types de tâches SSH, DNS, Ping, AMQP et génériques "exécuter une commande"
http://auxesis.github.com/cucumber- nagios /
http://www.slideshare.net/auxesis/behaviour-driven-monitoring-with-cucumbernagios-2444224
http://agilesysadmin.net/cucumber-nagios
Il y a aussi un effort du côté Puppet / Python des choses http://www.devco.net/archives/2010/03/27/infrastructure_testing_with_mcollective_and_cucumber.php