Agile DevOps ― гибкая разработка и эксплуатация ПО: Инфраструктура, управляемая тестами

Непрерывное тестирование среды, определяемой сценариями

Мало кто в индустрии программного обеспечения сомневается в том, что написание автоматизированных тестов для кода приложений ― хорошая практика. Теперь группы применяют аналогичную практику автоматизированного тестирования к инфраструктуре и рабочей среде. В этой статье из цикла Agile DevOps эксперт по DevOps Пол Дюваль говорит о написании автоматизированных тестов для инфраструктуры с использованием таких инструментов, как Cucumber и Gherkin. Эти тесты могут выполняться при каждом изменении сценария инфраструктуры для обеспечения быстрой реакции в том случае, если такое изменение вносит ошибку в рабочую среду.

Пол Дюваль, технический директор, Stelligent Incorporated

Paul DuvallПол Дюваль (Paul Duvall) является техническим директором компании Stelligent Incorporated – консалтинговой фирмы, которая помогает командам разработчиков оптимизировать гибкие методологии разработки программного обеспечения. Он также соавтор книги Continuous Integration: Improving Software Quality and Reducing Risk (Addison-Wesley, 2007 г.). Он принимал участие в создании книг UML 2 Toolkit (Wiley, 2003 г.) и No Fluff Just Stuff Anthology (Pragmatic Programmers, 2007 г.).



04.03.2013

Об этом цикле статей

Разработчики могут многому научиться у групп эксплуатации, а те ― у разработчиков. Эта серия статей посвящена изучению практического применения образа мышления групп эксплуатации к разработке и наоборот — а также рассмотрению программных продуктов в качестве целостных объектов, которые могут поставляться быстрее и чаще, чем когда бы то ни было.

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

  • Некоторые группы устанавливают и настраивают ресурсы, необходимые для создания рабочей среды, вручную. Обычно на то, чтобы получить среду в желаемом состоянии, уходят дни, недели или месяцы. За этот период времени члены группы могут уйти из компании или забыть точные операции, и больше никто уже не сможет воссоздать эту среду в ее первозданном виде.
  • Другие группы пытаются документировать каждый шаг по инициализации среды. Это благородные усилия, и это намного лучше, чем недокументированный процесс, однако документация быстро устаревает, становится некорректной или не соответствует действительности (из-за ошибок). По этим и другим причинам я не рекомендую использовать документацию в качестве протокола создания рабочей среды (хотя, как будет видно из следующего раздела, это может быть первым шагом к систематическому подходу к инициализации и тестированию среды).
  • Некоторые группы «погорели» на том, что было установлено вручную или документировано предыдущими группами. Будучи преисполнены решимости учиться на их ошибках, они автоматизировали процесс инициализации инфраструктуры с помощью набора сценариев. Спустя несколько месяцев и погрязнув в мириадах специальных оболочек и других сценариев, они решили, что эта среда оказалась слишком сложной для успешной автоматизации.

В противоположность этому, некоторые группы — прочитав о компаниях, внедряющих DevOps, — извлекли уроки из ошибок, связанных с ручной инициализацией, инициализацией на основе документов и набором разрозненных сценариев. Они избежали этих антимоделей с помощью подхода, ориентированного на тесты, наряду с использованием средств автоматизации зрелой инфраструктуры в рамках единого пути к производству. Как я уже упоминал в статье Автоматизация инфраструктуры, эти группы рассматривают инфраструктуру как код. Настоящий цикл статей помогает освоить подход к определению инфраструктуры, ориентированный на тесты.

Принципы и практика

Я неоднократно писал о непрерывном эвристическом процессе из пяти шагов (см. раздел Ресурсы). Вот эти шаги: документирование, тестирование, написание сценария, управление версиями и организация непрерывности процесса. Я опишу здесь каждый из этих шагов в контексте инфраструктуры, когда все шаги работают в ансамбле.

  • Документирование. Документирование этапов исполнения процесса. В случае инфраструктуры документируется тип и версия таких компонентов, как операционная система, приложение, Web-серверы и базы данных. Подробно описывается процесс установки, настройки и запуска всех этих компонентов инфраструктуры. При использовании этого подхода главное ― документирование с целью автоматизации, потому что в конечном итоге вы выкинете эту документацию.
  • Тестирование. Напишите автоматический тест, который описывает предполагаемый результат. В случае инфраструктуры можно определить функции или такие ожидаемые результаты, как сервер, работающий в определенном месте, или присутствие определенного файла или каталога.
  • Сценарий. Напишите сценарий всех действий процесса. В случае инфраструктуры для определения этих сред в соответствии с тестами, созданными на предыдущем шаге, используются такие инструменты, как Chef или Puppet.
  • Версирование. Версируйте исходные файлы. Для инфраструктуры эти файлы определяются в сценарии автоматизации инфраструктуры, созданном с помощью таких инструментов, как Puppet или Chef.
  • Непрерывность. Сценарий должен быть доведен до того состояния, когда он может работать в автоматическом режиме ― не требуя команд оператора для своего запуска. В случае инфраструктуры группы настраивают сервер непрерывной интеграции (CI), который исполняет сценарии автоматизации инфраструктуры и тестирования среды в рамках задачи CI — что означает, что инфраструктура будет перестраиваться при каждом изменении исходного файла.

Будьте в курсе

Раздел Agile transformation портала developerWorks содержит новости, обсуждения и учебные материалы, которые помогут вам и вашей организации строить фундамент на принципах гибкой разработки (EN).

Отличительной особенностью тестов инфраструктуры является порядок выполнения. Хотя можно использовать и подход "сначала тест", обычно сразу ко всей инфраструктуре применяются сценарии, а затем выполняются тесты для проверки эффективности автоматизации инфраструктуры. Эта последовательность отличается от тестирования модульного кода приложений, когда сначала запускается тест, а потом выполняется определенный метод или набор методов. По существу, в инфраструктуре на основе тестов нет никакой атомарности — вся среда создается целиком, а затем запускается набор тестов для этой новой среды.

Наиболее распространенный подход к применению инфраструктуры на основе тестов заключается в том, чтобы начать с документирования шагов по инициализации инфраструктуры. Основываясь на этой документации, инженер создает автоматические тесты, которые описывают результаты, ожидаемые от инфраструктуры. Эти тесты могут включать то, что группа рассчитывает получить, когда среда будет полностью инициализирована. Затем инженер пишет сценарии и вносит их в систему управления версиями. Наконец, сценарии и автоматические тесты запускаются в рамках системы CI. Некоторая комбинация этих шагов обеспечивает создание надежной инфраструктуры на основе тестов, которая гарантирует быструю обратную связь со всеми членами группы — хотя часто это не тот прямолинейный процесс «из учебника», который я описал.


Как это работает

Один из многих способов реализации инфраструктуры на основе тестов состоит в применении подхода разработки на основе поведения (BDD). Требования и тесты определяются в одном и том же файле, называемом файлом функции. Ниже я приведу некоторые примеры файлов функций, написанных на предметно-ориентированных языках (DSL) Cucumber и Gherkin.

В листинге 1 приведен файл функции Cucumber с именем production.feature, который описывает функцию, ее контекст и сценарии.

Листинг 1. Определение исполняемой спецификации в Cucumber и Gherkin
Feature: Scripted Provisioning of Target Environment
As a Developer
I would like my target environment provisioned correctly
so I can deploy applications to it

Background:
Given I am sshed into the environment

Scenario: Is the proper version of Postgresql installed?
When I run "/usr/bin/postgres --version"
Then I should see "8.4"

Scenario: Is the proper version of Apache installed?
When I run "/usr/sbin/httpd -v"
Then I should see "2.2"

Scenario: Is the proper version of Java installed?
When I run "java -version"
Then I should see "1.6"

Scenario: Is the proper version of perl installed?
When I run "perl -version"
Then I should see "perl, v5.10.1"

Scenario: Is the proper version of make installed?
When I run "make -version"
Then I should see "GNU Make 3.81"

Scenario: Is the proper version of Ruby installed?
When I run "ruby -v"
Then I should see "ruby 1.9.3"

Scenario: Is the proper version of GCC installed?
When I run "gcc -v"
Then I should see "4.4.6"

Feature, Background, Given, Scenario, When и Then ― все это специальные слова Cucumber, которые входят в DSL для определения файлов функций. Функция Scripted Provisioning of Target Environment в листинге 1 описывает ожидаемый результат на общеупотребительном языке, которым в организации пользуются все члены групп ― бизнес-аналитики, разработчики, тестеры, операторы и т.д. Для конкретных действий, таких как /usr/bin/postgres --version, используется Gherkin — сопутствующий инструмент, который устанавливается при установке Cucumber. Этот подход BDD позволяет определить исполняемую спецификацию, которая может выполняться посредством автоматизированных инструментов.

В листинге 2 приведен файл функции Cucumber с описанием способа указания того, что установлена определенная версия инструмента. Согласно этому подходу, сценарий инфраструктуры будет работать с любой из основных версий этого конкретного инструмента.

Листинг 2. Функция Cucumber, которая проверяет версию инструмента
Feature: Scripted Provisioning of Target Environment
As a Developer
I would like my target environment provisioned correctly
so I can deploy applications to it

Background:
Given I am sshed into the environment

Scenario: Is Tomcat installed?
When I check the version of Tomcat installed
Then the major version should be 6

В листинге 3 строки, следующие за ключевым словом Example, указывают, что поведение, описанное в сценарии, имеет несколько вариантов успешного результата.

Листинг 3. Описание примеров в Cucumber и Gherkin
Feature: Scripted Provisioning of Target Environment

As a Developer
I would like my target environment provisioned correctly
so I can deploy applications to it

Background:
Given I am sshed into the environment

Scenario Outline: Is the proper version of libxml2-devel installed?
When I run "sudo yum info libxml2-devel"
Then I should see "<output>"

Examples: output I should see
| output |
| Installed Packages |
| 2.7.6 |

Слабая связь

Связь между тестом и инфраструктурой не такая жесткая, как между тестами модулей (вроде тех, что написаны на JUnit) и кодом приложения. Например (и в напоминание о том, как описать среду сценарием), в листинге 4 приводится сценарий (или манифест) с использованием инструмента автоматизации инфраструктуры Puppet.

Листинг 4. Манифест Puppet, описывающий httpd-сервер с именем httpd
class httpd {
  package { 'httpd-devel':
    ensure => installed,
  }
  service { 'httpd':
    ensure => running,
    enable => true,
    subscribe => Package['httpd-devel'],
  }
}

Обратите внимание, что тест из листинга 1, в отличие от модульного теста для кода приложения, не выполняет этот манифест Puppet. Вместо этого конфигурация, определенная в манифесте (наряду со многими другими) сначала применяется к инфраструктуре для создания среды. Затем выполняется набор тестов, таких как те, что определены в листингах 1, 2 и 3, для проверки того, что среда находится в ожидаемом состоянии в соответствии с определением этих тестов.


Статический анализ

На момент написания этой статьи экосистема инструментов статического анализа при автоматизации инфраструктуры весьма бедна. Некоторые из инструментов, которые используются для статического анализа кода приложений, подходят для этой цели, но другие не поддерживают особенности сценариев инфраструктуры — главным образом потому, что те по своей природе не носят процедурный или объектно-ориентированный характер. Большинство из этих сценариев ― декларативные, то есть разработчики дают в них определение среды; сценарий отвечает за то, как на самом деле реализуется конфигурация с помощью инфраструктуры.

Такие инструменты, как Simian, полезны для определения разделов подобного кода. А foodcritic ― это lint-подобный инструмент для инструмента автоматизации инфраструктуры с открытым исходным кодом Chef. Что касается покрытия, то эффективный подход состоит в определении «требований покрытия» с помощью инструментов BDD, таких как Cucumber, а не традиционных инструментов для определения покрытия кода, применяемых к коду приложений — потому что в таких инструментах, как Chef и Puppet, не используется процедурный или объектно-ориентированный язык.


Все на основе тестов

В этой статье говорится о том, что инфраструктуру можно тестировать так же, как код приложения — или любую другую часть системы программного обеспечения. Приведены примеры реализации инфраструктуры на основе тестов с использованием Cucumber и поддержкой языка BDD Gherkin. Наконец, в ней показано, что хотя статический анализ инфраструктуры и отличается от статического анализа кода приложения, некоторые инструменты статического анализа все же можно использовать для совершенствования кода автоматизации инфраструктуры.

В следующей статье мы рассмотрим управление версиями всех компонентов системы программного обеспечения: инфраструктуры, кода приложений, конфигурации и данных.

Ресурсы

Научиться

Получить продукты и технологии

  • IBM Tivoli® Provisioning Manager: Tivoli Provisioning Manager позволяет создавать динамическую инфраструктуру, автоматизируя управление физическими серверами, виртуальными серверами, программным обеспечением, системами хранения данных и сетью.
  • cucumber-nagios: способ использования естественного языка для описания работы системы.
  • Foodcritic: lint-побобный инструмент для книг рецептов Chef Opscode.
  • IBM Tivoli System Automation for Multiplatforms: Tivoli System Automation for Multiplatforms обеспечивает высокую готовность и автоматизацию приложений и ИТ-услуг по всей организации.

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Технология Java, Open source
ArticleID=860304
ArticleTitle=Agile DevOps ― гибкая разработка и эксплуатация ПО: Инфраструктура, управляемая тестами
publish-date=03042013