Управление жизненным циклом приложений (Application Lifecycle Management, ALM) – одна из основных компетенций программного подразделения компании Hewlett-Packard, а теперь и ее преемницы Hewlett Packard Enterprise. Сегодня то, как разрабатываются, тестируются и вводятся в продуктив приложения, в огромной степени определяет потенциал цифровой трансформации бизнеса, и HPE, конечно, не может оставаться в стороне от этих тенденций. Эндрю Флик, технический директор линейки ALM/ALM Octane штаб-квартиры HPE, рассказывает о стратегических задачах и продуктах компании для реализации ALM нового поколения.

— Управление жизненным циклом приложений уже много лет в повестке дня вашей компании. Какова в настоящее время стратегия HPE в этой области?

Эндрю Флик
Эндрю Флик, технический директор линейки ALM/ALM Octane штаб-квартиры HPE: "Инструменты являются лишь частью сложного процесса миграции к новой парадигме разработки и жизненного цикла приложений. Чтобы успешно осуществить эту миграцию, нужны люди, которые понимают, как устроена современная разработка, и нужна воля к изменению процессов"

Стратегия HPE ALM имеет три основных составляющих. Во-первых, мы исходим из того, какими ресурсами в этой области уже обладаем. HPE принадлежит 32% рынка автоматизации управления качеством корпоративного ПО, общий объем которого составляет 2 млрд долл., нашими клиентами являются 24 из Top 25 компаний мира. Мы предлагаем такие зарекомендовавшие себя решения, как HPE Quality Center и HPE ALM, ориентированные преимущественно на корпоративных пользователей. Другой важный компонент нашего продуктового портфеля – продукт Agile Manager, предназначенный для команд разработчиков, которые работают по Agile-методологиям. В последние годы очевиден рост популярности Agile и расширение масштабов таких проектов. Мы должны учитывать тенденцию проникновения Agile в корпоративный сектор, и потому первым направлением стратегии HPE ALM является предоставление тех возможностей, которыми обладают Quality Center, ALM и Agile Manager, в качестве единой платформы для управления жизненным циклом приложений.

В то же время активное применение Agile в корпоративных проектах создает потребность во внедрении подходов DevOps. Но реализация DevOps всегда опирается на разнородную цепочку решений. И мы должны принять как должное тот факт, что, если существуют разумные альтернативы Open Source, не имеет смысла пытаться с ними конкурировать. Зачем разрабатывать собственный инструмент управления версиями, если есть Git, или свой сервер непрерывной интеграции, если доступен Jenkins. Корпоративные команды DevOps будут выбирать для отдельных задач лучшие в своем классе решения, представленные на рынке. Поэтому вторая ключевая составляющая стратегии HPE ALM – обеспечение гетерогенности в жизненном цикле приложения: поддержка систем с открытым кодом и предоставление возможностей интеграции с продуктами конкурентов, такими как TFS, Jira или Rational.

Третье направление, которое мы называем прогнозным (predictive) ALM, связано с тем, что в ходе реализации жизненного цикла приложения собираются огромные массивы данных. Пару лет назад я взял на работу несколько data scientists, а сейчас у нас уже целая команда таких специалистов. Они работают над сложной задачей использования исторических данных для предсказания будущих результатов. Например, на основе базы данных ALM, которую мы используем в НРE, и базы данных Service Manager обо всех инцидентах в компании разрабатывается алгоритм, который позволит определить, какого количества инцидентов можно будет избежать в продуктивной среде, если в ходе тестирования будет выявлен тот или иной дефект в определенной функциональной области.

— Какое отражение эти три направления стратегии находят в продуктовом портфеле HPE?

1 июня на рынок был выпущен новый продукт, HPE ALM Octane, который отвечает основным задачам первого и второго направлений. Ключевой бекграунд HPE в области ALM – это автоматизация всего спектра проблем обеспечения качества ПО, поэтому прежде всего в унифицированном продукте ALM Octane мы представили более свежий взгляд на эти задачи. При этом на той же платформе вы получаете, с одной стороны, управление беклогами и другие Agile-возможности, а с другой – необходимую для предприятий поддержку рабочих процессов и настраиваемых бизнес-правил. Таким образом, это решение отвечает потребностям как наших традиционных корпоративных заказчиков, так и новых пользователей, которые практикуют Agile-разработку.

Для реализации второго направления стратегии – поддержки перехода к DevOps – мы особое внимание уделяем открытости платформы и возможностям интеграции. ALM Octane поддерживает серверы непрерывной интеграции Jenkins и TeamCity, позволяет работать с Git для хранения тестов и предоставляет средства интеграции с классическими ALM-продуктами,такими как Jira, TFS и Rational Team Concert.

Работа над прогнозным ALM ведется, в этом году выпущен technical preview решения под названием Predictive Defect Convergence. Оно позволяет, например, спрогнозировать дату исправления всех ошибок при известном числе разработчиков в команде и выполнять анализ «что-если»: когда будут устранены все дефекты, если число разработчиков увеличить или, наоборот, уменьшить.

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

— Каким заказчикам вы будете рекомендовать миграцию на ALM Octane или внедрение этого решения?

Среди клиентов ALM сегодня можно наблюдать определенное расслоение. Есть так называемые базовые ИТ, для которых важно следование определенным регуляторным правилам. Такие заказчики проявляют интерес к ALM Octane и делают попытки внедрять этот продукт, но при этом им приходится решать задачу изменения самих основ своих процессов. На другом полюсе – компании, которые уже стали цифровым бизнесом, и их все больше. Они с радостью берут ALM Octane и отмечают, что этот продукт отвечает всем их потребностям – обеспечивает непрерывную интеграцию, управление версиями и т. д. — все то, что они уже так или иначе делают, и там внедрение проходит без проблем.

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

Хочу также отметить, что нашим заказчикам, которые имеют действующий контракт на поддержку продуктов HPE ALM и HPE Quality Center, не нужно будет покупать ALM Octane – они получат это решение в рамках своих соглашений. Тем самым мы демонстрируем рынку, что видим происходящие на нем важные изменения и хотим поддержать компании, которые эволюционируют в сторону DevOps.

— Насколько сложным будет переход на новое решение для пользователей ваших ALM-продуктов предыдущего поколения?

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

— Если ALM Octane призван помочь в переходе к DevOps, то где в нем место для Ops?

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

Второе направление, которое мы тоже будем активно развивать, связано с поддержкой современных инструментов совместной работы различных команд в DevOps. В ALM Octane представлен новый бот ChatOps, с помощью которого это решение может интегрироваться с Slack, Flowdoc или любым другим инструментом коммуникаций между командами. Мы приняли во внимание тот эволюционный путь, который прошла ИТ-организация самой HP, реализуя новые принципы взаимодействия между HP Dev и HP Ops. В больших корпорациях очень непросто ломать барьеры между существующими оргструктурами. Но есть общие инструменты, которые используют разные команды, прежде всего это средства коммуникаций – с их помощью переход к DevOps можно упростить.

— Используются ли в ALM Predictive технологии из портфеля НРЕ для работы с Большими Данными?

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

— Какие тенденции вы видите на рынке ALM?

Скорее надо смотреть на рынок управления ИТ в целом, который включает в себя четыре области: управление проектами и портфелями (РРМ), управление жизненным циклом приложения (ALM), управление производительностью приложений (АРМ) и управление сервисами. В каждой из этих основных областей происходят инновации, которые несут угрозу стабильности этих классических многомиллиардных рынков. Например, на рынок ALM серьезно влияет рапространение Agile, поэтому он показывает небольшой рост в 3%, а на самом деле, возможно, вообще не растет, поскольку в рамках этого рынка возникает новый – рынок Agile-решений, который оттягивает на себя прибыль. Однако интересно то, что, будучи частью рынка ALM, рынок Agile включает в себя компоненты рынка РРМ. Таким образом, все эти рынки сближаются и эволюционируют, и мы не должны рассматривать их в изоляции друг от друга, если хотим принимать правильные решения в отношении управления ИТ, в том числе с точки зрения стратегических инвестиций.