Введение: О методологии DevOps

DevOps - это методология циклов выпуска программного обеспечения, реализующая единый подход к его разработке и эксплуатации. На самом простом уровне суть DevOps заключается в попытке ответить на вопрос: "Каков наиболее эффективный способ реализации хорошей идеи?".

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

Что это означает? Методология DevOps начинается и заканчивается клиентом. Требование клиента запускает цикл разработки. Первым шагом к пониманию того, как можно удовлетворить требование клиента, является планирование. Необходимо оперативно реагировать на отзывы клиента. Бережливые и гибкие методы облегчают быстрое реагирование. Например, одним из принципов бережливого подхода является выпуск продукта как можно раньше. Для достижения этой цели можно исключить предварительное масштабное проектирование, которое может приводить к необходимости последующей переработки, а значит, к задержкам. Вместо этого проектная группа может зафиксировать требования к функции и приступить работе над ней, когда будет готова ее создать.

За планированием следует разработка. И здесь также важную роль в DevOps играют гибкие методы, в особенности короткие итерации, позволяющие создавать быстро развертываемые артефакты. Элементами методологии DevOps являются такие методы, как непрерывная интеграция, автоматизированное тестирование и непрерывное тестирование.

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

Разбиение проекта IBM BPM в соответствии с концепциями DevOps

Теперь, получив общее представление о подходе DevOps, подумайте о том, как его можно применить к проекту IBM Business Process Manager (BPM). Рассматривайте весь подход, от этапа изучения до развертывания в производственной среде.

Этапы изучения и проектирования на макроуровне

Перед началом проекта IBM BPM важно ответить на вопрос: "Какой процесс мы намерены реализовать?".

Проанализировав процессы, можно определить, какие из них готовы к реализации. Применение критериев, ориентированных на выгоды для клиента, помогает определить приоритеты и отобрать процессы исходя из ценности, которую они приносят клиенту. Такая ориентация на предоставляемые выгоды лежит в основе метода Smarter Process Method, который включает оценку процессов, создание плана и выполнение анализа отклонений. Свяжитесь со службой IBM Services, если хотите узнать, как использовать метод Smarter Process Method в своем проекте.

После выбора процесса наступает время для применения методологии DevOps. Процесс IBM BPM не находится в изоляции. Он интегрируется с другими системами. На этапе исследования необходимо определить такие системы и предоставляемые ими сервисы. Группа эксплуатации может ответить на вопросы о сервисах, в том числе относящиеся к соглашениям об уровнях обслуживания (Service Level Agreement, SLA) и качеству обслуживания (Quality Of Service, QoS).

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

Чтобы включить методологию DevOps в сбор требований, аналитикам и архитекторам IBM BPM необходимо выйти за пределы модели "как есть" и ее ограничений - и рассматривать то, что должно быть, и то, что может быть. И в конечном итоге группа представляет себе модель "как будет".

На основе требований создаются пользовательские истории. Проектная группа отображает пользовательские истории на процесс в соответствии с тем, как эти истории связаны с пользователем или другой системой, их действиями, их задачами или ожидаемыми выгодами. Исследования завершаются презентацией Playback Zero (Воспроизведение 0), где все заинтересованные стороны встречаются, чтобы понять модели, ценности и содержание процесса.

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

Этап разработки

В проекте по разработке IBM BPM следует применять гибкие методики и принципы. Ключевыми принципами являются тесная работа с клиентом над каждой функцией, управление техническим долгом и сведение расходов к минимуму. В ходе типичного проекта IBM BPM программисты работают в среде Process Designer над текущей версией приложения (последней "главной" версией). Для эффективной реализации непрерывной интеграции группа должна внедрить автоматизированный метод получения снимков (например, "помеченной" версии) и их развертывания на сервере Process Server.

Непрерывное тестирование является еще одним центром внимания на этапе разработки. Тестирование текущей версии в ходе разработки может приводить к ошибкам просто по причине продолжающейся работы над компонентами. Обычно для исключения таких проблем в известное время делается моментальный снимок, который можно отправлять в среду Process Server для тестирования разработки. Как уже описывалось, подход DevOps требует автоматизированного способа получения снимка для непрерывного тестирования. Автоматизированное тестирование также может быть проблемой, как минимум с точки зрения пользовательского интерфейса. По мере развития объекта coach (пользовательского интерфейса в IBM BPM) также необходимо загружать сценарии автоматизированного тестирования. Для других компонентов решения, таких как средства интеграции, рассмотрите возможность использования наборов тестов, которые можно было бы написать один раз и использовать многократно. Для тестирования входа и выхода служб взаимодействий с пользователями, содержащих объекты coach, можно использовать тестовые наборы.

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

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

Некоторые организации не начинают приемочное тестирование до завершения разработки. Вместо применения такого подхода привлекайте конечных пользователей с самых ранних этапов проекта. Бизнес-группе и экспертам в предметной области следует проводить презентации воспроизведения в конце каждой итерации, не только чтобы продемонстрировать, что было разработано под их руководством, но и чтобы получить одобрение предоставляемых пользовательских историй от реальных конечных пользователей. Воспроизведение также является введением в тестирование, когда группы бизнес-специалистов, разработчиков и тестировщиков приходят к единому мнению о том, какие истории готовы к тестированию в конце итерации. Не следует ждать окончания разработки, чтобы приступить к тестированию. Более обширное тестирование можно будет выполнить после достижения критической массы в разработке процесса. Чтобы эти действия были эффективными и прозрачными, используйте такие инструменты, как IBM Rational Functional Tester, позволяющие группе видеть статус каждой пользовательской истории и помечать пользовательские истории как принятые после прохождения проверки.

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

Непрерывный поток

Представляйте себе процесс разработки как один непрерывный поток. У владельца процесса есть пользовательские истории, упорядоченные по приоритетности. Разработчики берут следующую по приоритетности пользовательскую историю из списка и вместе с владельцем процесса и экспертами в предметной области разрабатывают ее. Они демонстрируют историю владельцу процесса, который затем ее принимает. Владелец процесса выполняет тестирование, после чего история готова к выпуску в рабочую среду. Если ваше приложение процесса характеризуется высоким уровнем модульности, то эту методику можно применять к небольшим самоуправляемым группам представителей бизнес-подразделений и отделов разработки, тестирования и эксплуатации.

Этапы развертывания и эксплуатации

Для создания снимка и отправки его на сервер среды исполнения можно использовать средства автоматизированного развертывания в IBM BPM. Из консоли Process Center снимки можно автоматически отправлять на любые серверы в сети, от среды тестирования до рабочей среды. Но это не единственный вариант развертывания. При отсутствии прямого соединения между Process Center и Process Server можно выполнять автономное развертывание. Рассмотрите вариант автономного развертывания, если хотите ограничить круг специалистов, которые могут выполнять развертывание в рабочей среде или если хотите реализовать подход DevOps в более сложной среде.

До этого момента мы рассматривали подход DevOps исключительно в отношении IBM BPM, но что если решение является более сложным? Например, возможно, вы используете IBM BPM без графического интерфейса в сочетании с мобильным интерфейсом, или конфигурируете облачное решение, или выпускаете сложное решение с множеством связанных элементов кода, когда коды для всех компонентов должны координироваться и развертываться совместно.

При работе с более сложными решениями обратите внимание на такой инструмент, как IBM UrbanCode Deploy. Каждый компонент, включая IBM BPM, можно сконфигурировать как компонент одного общего приложения. В случае IBM BPM режим автономного развертывания на сервере можно использовать для всех сред, а не только производственной. Например, если пришло время приемочных испытаний, все компоненты можно развернуть в среде приемочного тестирования в одно и то же время, будь то IBM BPM, мобильный интерфейс или любой другой код. При использовании IBM Urban Code Deploy становится возможным непрерывное развертывание, поскольку все компоненты управляются совместно.

Цикл обратной связи

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

Мониторинг - это не только проверка соответствия целям бизнеса. Позаботьтесь о мониторинге работоспособности приложения. Отслеживание таких параметров, как потребление процессорных ресурсов или оперативной памяти, позволяет выявлять проблемы, требующие решения. Группе эксплуатации необходимо в ходе разработки совместно с разработчиками определить потребности в мониторинге. Это еще одна область, где в игру вступают нефункциональные требования. Например, может существовать нефункциональное требование, которое указывает, что запрос к базе данных должен возвратить ответ в течение 2 секунд. Решение должно предоставлять возможность отслеживания выполнения такого соглашения об уровне обслуживания, а группа эксплуатации должна позаботиться о его соблюдении. При возникновении проблемы группа эксплуатации может совместно с разработчиками заняться ее решением.

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

Заключение

В этом руководстве описаны некоторые концепции подхода DevOps и методы их применения к проектам IBM BPM. IBM BPM позволяет легко реализовать возможности DevOps, включая непрерывную интеграцию и автоматизированное развертывание.

Если решение включает не только IBM BPM, оно становится более сложным, и тогда следует рассмотреть применение более сложного подхода к DevOps с использованием таких инструментов, как IBM UrbanCode Deploy.

Теперь вы можете планировать применение подхода DevOps к вашим проектам IBM BPM.