+7 (495) 229-0436   shopadmin@itshop.ru 119334, г. Москва, ул. Бардина, д. 4, корп. 3
 
 
Вход
 
 
Каталог
 
 
Подписка на новости:
Новости ITShop
Windows 7 и Office: Новости и советы
Обучение и сертификация Microsoft
Вопросы и ответы по MSSQLServer
Delphi - проблемы и решения
Adobe Photoshop: алхимия дизайна
 
Ваш отзыв
Оцените качество магазина ITShop.ru на Яндекс.Маркете. Если вам нравится наш магазин - скажите об этом Google!
 
 
Способы оплаты
Яндекс.Деньги VISA, EUROCARD/MASTER CARD, DCL, JCB WebMoney RBK Money Деньги@mail.ru Сбербанк РФ ASSIST QIWI кошелек
 
Курс расчета
 
 1 у.е. = 58.71 руб.
 
 Цены показывать:
 
 
 
 
  
Новости, статьи, акции
 

Применение концепций DevOps к проекту IBM Business Process Manager

21.08.2015 15:22

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

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

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

Испытайте сервис Workflow

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

Что это означает? Методология 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 в сбор требований, аналитикам и архитекторам IBM BPM необходимо выйти за пределы модели "как есть" и ее ограничений - и рассматривать то, что должно быть, и то, что может быть."

На этапе исследования начинается процесс сбора требований, обычно в виде пользовательских историй. Проектная группа не должна игнорировать нефункциональные требования, в том числе относящиеся к 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.

  
Помощь
Задать вопрос
 программы
 обучение
 экзамены
 компьютеры
Бесплатный звонок
ICQ-консультанты
Skype-консультанты

Общая справка
Как оформить заказ
Тарифы доставки
Способы оплаты
Прайс-лист
Карта сайта
 
Популярные статьи
Разработка ПО СУБД и хранилища данных Резервное копирование Информационная безопасность Средства тестирования Microsoft Офисное ПО Графические редакторы САПР Управление разработкой ПО Разработка веб-приложений Разработка отчетных форм Операционные системы Linux Антивирусное ПО и защита от спама Интернет ИТ-Обучение AutoDesk IBM Свободное ПО Embarcadero ИТ-Сертификация Eset Software Доктор Веб Лаборатория Касперского Developer Express Inc. Clouds Мобильные приложения Micro Focus Robots Blockchain ISpring
 
Бестселлеры
Курсы обучения "Atlassian JIRA - система управления проектами и задачами на предприятии"
Microsoft Office 365 для Дома 32-bit/x64. 5 ПК/Mac + 5 Планшетов + 5 Телефонов. Подписка на 1 год. Электронный ключ
Microsoft Windows 10 Профессиональная 32-bit/64-bit. Все языки. Электронный ключ
Microsoft Office для Дома и Учебы 2016. Все языки. Электронный ключ
Курс "Oracle. Программирование на SQL и PL/SQL"
Курс "Основы TOGAF® 9"
Microsoft Windows Professional 10 Sngl OLP 1 License No Level Legalization GetGenuine wCOA (FQC-09481)
Microsoft Office 365 Персональный 32-bit/x64. 1 ПК/MAC + 1 Планшет + 1 Телефон. Все языки. Подписка на 1 год. Электронный ключ
Windows Server 2016 Standard
Курс "Нотация BPMN 2.0. Ее использование для моделирования бизнес-процессов и их регламентации"
Антивирус ESET NOD32 Antivirus Business Edition
Corel CorelDRAW Home & Student Suite X8
 

О нас
Интернет-магазин ITShop.ru предлагает широкий спектр услуг информационных технологий и ПО.

На протяжении многих лет интернет-магазин предлагает товары и услуги, ориентированные на бизнес-пользователей и специалистов по информационным технологиям.

Хорошие отзывы постоянных клиентов и высокий уровень специалистов позволяет получить наивысший результат при совместной работе.

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



 

О нас

 
Главная
Каталог
Новинки
Акции
Вакансии
 

Помощь

 
Общая справка
Как оформить заказ
Тарифы доставки
Способы оплаты
Прайс-лист
Карта сайта
 

Способы оплаты

 

Проекты Interface Ltd.

 
Interface.ru   ITShop.ru   ERPforum.ru    Interface.ru/training   Olap.ru   Job.com.ru   ITnews.ru  
 

119334, г. Москва, ул. Бардина, д. 4, корп. 3
+7 (495) 229-0436   shopadmin@itshop.ru
Rambler's Top100 Проверить аттестат Товары@Mail.ru
© ООО "Interface Ltd."
Продаем программное обеспечение с 1990 года