Разработка через тестирование для развертываний инфраструктуры?

Я не думаю, что Вы могли использовать разработку через тестирование. Но Вы могли, конечно, попробовать поблочное тестирование на новых серверах.

В основном необходимо было бы развернуть серверы, запустить сервисы в тестовом режиме и затем запустить тесты с другого сервера (или серия серверов) против сервисов. Затем наконец введите их в эксплуатацию.

Возможно, с помощью сценариев Python для соединения с базами данных, веб-страницами и ssh сервисами. И затем возвратите ПЕРЕДАЧУ/СБОЙ. Было бы хорошее начало для Вас.

Или Вы могли просто свернуть это в решение по контролю, как Zenoss, Nagios или Munin. Затем можно протестировать, во время развертывания; И монитор во время производства.

Я думаю, что Joseph Kern на правильном пути с контрольными инструментами. Типичный цикл TDD: запишите новый тест, который перестал работать, затем обновите систему так, чтобы все существующие тесты передали. Это было бы легко адаптировать к Nagios: добавьте провальную проверку, настройте сервер, повторно выполните все проверки. Задумайтесь о нем, я иногда делал точно это.

Если бы Вы хотите получить действительно хардкор, Вы удостоверились бы, что записали сценарии для проверки каждого соответствующего аспекта конфигураций сервера. Система контроля как Nagios не могла бы быть важна для некоторых из них (например, Вы не могли бы "контролировать" свою версию ОС), но нет никакой причины, Вы не могли смешивание и подгонка как соответствующее.

В то время как я не смог сделать TDD с Марионеточными декларациями все же, у нас действительно есть довольно хороший цикл, чтобы препятствовать тому, чтобы изменения вошли в производство без тестирования. У нас есть два настроенные puppetmasters, каждый - наше производство puppetmaster, и другой наша разработка puppetmaster. Мы используем "среды" Марионетки для установки следующего:

• среды разработки (один для каждого человека, работающего над Марионеточными декларациями)
• тестовая среда
• продуктивная среда

Наши разработчики приложений делают свою работу над виртуальными машинами, которые получают их Марионеточные конфигурации от среды "тестирования" Puppetmaster разработки. Когда мы разрабатываем Марионеточные декларации, мы обычно настраиваем VM, чтобы служить тестовым клиентом во время процесса разработки и указать на него на нашу персональную среду разработки. После того как мы довольны нашими декларациями, мы продвигаем их к тестовой среде, где разработчики приложений получат изменения на своем VMs - они обычно жалуются громко, когда что-то повреждается :-)

На представительном подмножестве наших производственных машин существует второй puppetd, работающий в noop режиме, и указал на тестовую среду. Мы используем это для ловли потенциальных проблем с декларациями, прежде чем они будут продвинуты к производству.

После того как изменения передали, т.е. они не повреждают машины разработчика приложений, и они не производят нежелательный вывод в журналах производственных машин "noop" puppetd процесс, мы продвигаем новые декларации в производство. Мы имеем в распоряжении механизм отката, таким образом, мы можем вернуться к более ранней версии.

Я работал в среде, которая была в процессе миграции на операционную модель TDD. Для некоторых вещей как контролирующие сценарии это работало очень хорошо. Мы использовали buildbot, чтобы установить тестовую среду и запустить тесты. В этом случае Вы приближаетесь к TDD с точки зрения "Унаследованного кода". В TDD "Унаследованный код" существующий код, который не имеет никаких тестов. Таким образом, первые тесты не перестали работать, они определяют корректный (или ожидаемый) операция.

Для многих заданий конфигурации первый шаг должен протестировать, может ли конфигурация быть проанализирована сервисом. Многие сервисы предоставляют некоторые услуги, чтобы сделать просто это. Nagios имеет режим перед полетом, cfagent не имеет никакого действия, апачи, sudo, связывают, и у многих других есть подобные средства. Это - в основном линт, выполненный для конфигураций.

Пример был бы то, при использовании апача и отдельных файлов конфигурации для отличающихся частей можно протестировать части, также просто используют другой httpd.conf файл для обертывания их для работы тестовой машины. Затем можно протестировать это, веб-сервер на тестовой машине дает корректные результаты там.

Каждый шаг по пути Вы следуете за тем же основным шаблоном. Запишите тест, сделайте тестовую передачу, осуществите рефакторинг работу, которую Вы сделали. Как упомянуто выше, при следовании за этим путем, тесты не могут всегда перестать работать принятым способом TDD.

Rik

Я полагаю, что следующие ссылки могли представлять интерес

1. огурец-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

2. Существует также некоторое усилие на стороне Марионетки/Python вещей http://www.devco.net/archives/2010/03/27/infrastructure_testing_with_mcollective_and_cucumber.php