Я використовую маріонетки для розгортання інфраструктури, і більшу частину роботи я роблю з компаніями Web 2.0, які сильно займаються розробкою тестових програм для своїх веб-додатків. Хтось тут використовує тестовий підхід для розробки своїх конфігурацій сервера? Які інструменти ви використовуєте для цього? Наскільки глибоко проходить тестування?
Відповіді:
Я не думаю, що ви могли використовувати тестові розробки . Але ви, безумовно, можете спробувати блок-тестування на нових серверах.
В основному вам потрібно буде розгорнути сервери, запустити служби в тестовому режимі, а потім запустити тести з іншого сервера (або серії серверів) проти служб. Тоді нарешті вводять їх у виробництво.
Можливо, використання сценаріїв python для підключення до баз даних, веб-сторінок і служб ssh. А потім поверніть PASS / FAIL. Було б хорошим початком для вас.
Або ви могли просто згорнути це в моніторингові рішення, як-от Zenoss, Nagios або Munin. Потім ви можете протестувати під час розгортання; І стежте за виробництвом.
Я думаю, що Джозеф Керн на правильному шляху з інструментами моніторингу. Типовим циклом TDD є: написати новий тест, який не працює, а потім оновити систему, щоб усі існуючі тести пройшли. Це було б легко адаптуватися до Nagios: додайте невдалий чек, налаштуйте сервер, повторно запустіть усі перевірки. Подумайте про це, іноді я робив саме це.
Якщо ви хочете отримати справді важкі сердечники, ви б обов'язково написали сценарії, щоб перевірити кожен відповідний аспект конфігурації сервера. Система моніторингу, як Nagios, може бути нерелевантною для деяких із них (наприклад, ви не можете "контролювати" свою версію ОС), але немає причин, щоб ви не могли змішувати та відповідати відповідно.
Поки мені ще не вдалося зробити TDD з маріонетними маніфестами, у нас є досить хороший цикл, щоб запобігти вступу змін у виробництво без тестування. У нас створено двох лялькових майстрів, один - наш ляльковий майстер, а другий - наш ляльковий розробник. Ми використовуємо "середовища" Лялечки для налаштування наступного:
Наші розробники додатків роблять свою роботу на віртуальних машинах, які отримують їхні конфігурації ляльок із середовища «тестування» Puppetmaster. Коли ми розробляємо маніфест ляльок, ми зазвичай встановлюємо VM, щоб він був тестовим клієнтом під час процесу розробки і вказував на це наше особисте середовище розвитку. Як тільки ми задоволені нашими маніфестами, ми підштовхуємо їх до тестового середовища, де розробники додатків отримують зміни у своїх віртуальних машинах - вони зазвичай голосно скаржаться, коли щось зламається :-)
На репрезентативному підмножині наших виробничих машин є другий ляльковик, що працює в режимі noop і вказує на тестувальне середовище. Ми використовуємо це, щоб вирішити потенційні проблеми з маніфестами, перш ніж їх підштовхнуть до виробництва.
Після того, як зміни пройдуть, тобто вони не порушують машини розробника додатків і вони не виробляють небажаного виводу в журналах процесу "noop" маріонетки машин виробництва, ми підштовхуємо нові маніфести до виробництва. У нас є механізм відкату, щоб ми могли повернутися до попередньої версії.
Я працював у середовищі, яке переходило до моделі операцій TDD. Для деяких речей, таких як сценарії моніторингу, це спрацювало дуже добре. Ми використовували buildbot для установки тестового середовища та проведення тестів. У цьому випадку ви підходите до TDD з точки зору "Спадкового кодексу". У TDD "Legacy Code" є існуючий код, який не має тестів. Тож перші тести не провалюються, вони визначають правильну (або очікувану) роботу.
Для багатьох завдань з конфігурації перший крок - перевірити, чи може конфігурація проаналізована службою. Багато служб надають певні можливості зробити саме це. У Nagios є передпольотний режим, cfagent не діє, апаш, судо, бінд, а багато інших мають подібні засоби. Це в основному пробіжка для конфігурацій.
Прикладом може бути, якщо ви використовуєте apache та окремі конфігураційні файли для різних частин, ви можете протестувати деталі, а також просто використовувати інший файл httpd.conf, щоб обернути їх для роботи на вашій тестовій машині. Тоді ви можете перевірити, що веб-сервер на тестовій машині там дає правильні результати.
Кожен крок по шляху ви дотримуєтесь тієї ж основної схеми. Напишіть тест, зробіть тестовий пропуск, рефакторируйте виконану вами роботу. Як було сказано вище, при дотриманні цього шляху випробування не завжди можуть бути невдалі прийнятим методом TDD.
Рік
Вважаю, що наступні посилання можуть зацікавити
cucumber-nagios - проект, який дозволяє вам перетворити набір огірків у плагін Nagios, який містить крокові визначення для SSH, DNS, Ping, AMQP та загальні типи завдань "виконувати команду"
http://auxesis.github.com/cucumber- nagios /
http://www.slideshare.net/auxesis/behaviour-driven-monitoring-with-cucumbernagios-2444224
http://agilesysadmin.net/cucumber-nagios
Також є певні зусилля з боку лялькових / пітонних речей http://www.devco.net/archives/2010/03/27/infrastructure_testing_with_mcollective_and_cucumber.php