Создание приложений — комплексный процесс, который включает в себя несколько элементов: написание кода, тестирование, устранение ошибок, проверку и, наконец, запуск в эксплуатацию. Можно сказать, что в этом процессе участвуют три независимых «государства» — разработчики, тестировщики и сотрудники отдела эксплуатации. Каждая из этих групп выполняет собственные задачи и пользуется разными критериями оценки эффективности своей работы. Для разработчиков — это скорость написания и количество реализованных в программном коде функций, для тестировщиков — число выявленных ошибок, для отдела эксплуатации — стабильность функционирования систем и минимальное количество инцидентов. Подобная модель работы нередко приводит к конфликту интересов: первые стараются как можно быстрее написать код и отдать его на проверку, вторые готовы проверять и тестировать сколь угодно долго, чтобы выявить все баги, а третий с трудом принимает код, поскольку любые изменения влекут за собой потенциальные риски для всей ИТ-инфраструктуры. В итоге весь процесс создания приложений растягивается надолго, что с учетом сложной экономической ситуации совершенно недопустимо, ведь бизнес должен быть максимально гибким и клиентоориентированным, а выпуск новых продуктов и услуг своевременным.
Разумеется, многие компании уже давно осознали неэффективность подобной модели выпуска приложений и начали поиски способов её оптимизации. Одним из таких способов является модель Agile, которая предусматривает плодотворное взаимодействие отделов разработки и тестирования, осуществляемое в соответствии с общими целями, общими правилами и общими критериями эффективности. При этом отдел эксплуатации все еще остается «за рамками» модели Agile. Если разработчики и тестировщики заинтересованы в как можно более быстром создании работоспособного кода, ошибок в котором нет, то эксплуатация, как и прежде, не готова к новым подходам. Ведь любое изменение, вносимое с появлением нового программного кода, чревато потенциальными аварийными ситуациями и другими нежелательными инцидентами в работе ИТ-инфраструктуры. Существует вероятность того, что с установкой новой версии программного обеспечения, все попросту «рухнет». Именно этого и опасаются специалисты служб эксплуатации, и зачастую такие опасения небезосновательны.
Необходимо устранить последнюю преграду между разработчиками и тестировщиками, с одной стороны, и службами эксплуатации, с другой. Эту задачу призвана решить методология DevOps, которая, по сути, расширяет рамки Agile, вовлекая в них подразделения по эксплуатации, но не только. Ее можно реализовать и в традиционной классической модели разработки Waterfall. Возможны варианты, когда одна часть команды работает по методологии Agile, а другая — по Waterfall. При этом переход на DevOps позволит учесть общие интересы и критерии, чтобы наладить совместное эффективное взаимодействие буквально всех подразделений — разработчиков, тестировщиков и специалистов по эксплуатации. Ведь суть DevOps не только в формализованных процессах, но в изменении культуры разработки программного обеспечения.
Что же поможет реализовать методологию DevOps в компании? В первую очередь нужны такие подходы, которые максимально автоматизируют все процессы и цикл разработки в целом. Поскольку цикл разработки велик и многогранен, для его автоматизации используется широчайший спектр продуктов, среди которых и решения компании HPE, и приложения сторонних разработчиков, в том числе свободное ПО.
Ho DevOps состоит не только из технологий. Не менее важная роль отводится взаимодействию людей и процессам. По данным Gartner, опубликованным в конце прошлого года, 50% успеха проектов DevOps кроется именно в человеческом факторе, 37% — в процессах, и только 8% — в технологиях. Зачастую заказчики надеются, что после установки и интеграции всех необходимых программных продуктов у них заработает DevOps, но подобные проекты проваливаются чаще всего. Пока люди не станут единой командой с общими интересами и критериями эффективности, DevOps функционировать не сможет. Пока специалисты по эксплуатации не осознают свою ответственность еще на этапе постановки требований, а разработчики не будут отвечать за качество кода в эксплуатации, методология DevOps останется невостребованной.
Что же необходимо предпринять для создания единой команды по правилам DevOps? Прежде всего нужно выяснить, как работают сотрудники, что им помогает, а что мешает. Существует немало различных образовательных курсов по построению DevOps, есть такие курсы и у HPE. Если в организации используются не только классические Waterfall-подходы к разработке, но и методы Agile, следует подумать о масштабировании всего процесса, в котором участвует несколько команд. В качестве наиболее эффективного инструмента для решения этой задачи HPE рекомендует Scaled Agile Framework.
HPE активно готовит и уже запустила часть учебных курсов по переходу и освоению методологии DevOps. Один из них, DevOps Awareness, доступен и в России; в нем рассказывается об общих принципах методологии и о специализированных подходах компании HPE. Кроме того, для российских пользователей уже практически готовы другие курсы: углубленный по DevOps, по его использованию на практике, а также по сопутствующим программным продуктам.
Какую реальную экономическую выгоду для заказчика способен принести переход на модель DevOps? Методологически она базируется на Scaled Agile Framework, который позволяет вычислить преимущества в рублях и процентах при переходе на DevOps с Waterfall, Agile и в случае смешанных вариантов. По сути, DevOps можно сравнить с автомобильным конвейером, максимально быстро выводящим готовый автомобиль от инженера до потребителя. В сравнении с Waterfall, к примеру, у DevOps есть неоспоримое преимущество: максимальное снижение рисков при развертывании благодаря автоматизации всех процессов. При разработке по модели Waterfall примерно треть всех погрешностей обусловлена человеческим фактором: люди ошибаются при внесении изменений, при подготовке инфраструктуры и т.д. Чаще всего эти ошибки возникают из-за того, что у различных подразделений, участвующих в создании программного обеспечения, нет общих инструментов и отсутствует возможность делиться полученными знаниями. Еще один немаловажный момент — размывание ответственности, когда каждый специалист отвечает только за свой узкий участок.
Теперь немного о том, как реализована продуктовая поддержка DevOps. Сначала в продуктах HPE Project Portfolio Manager и Service Manager происходит планирование изменений. Сюда относятся потребности и запросы, о которых сообщает бизнес.
Кроме того, при помощи Service Manager служба эксплуатации может сообщить, какие изменения нужно внести в программный код для устранения конкретного инцидента, и эти изменения сразу же трансформируются в задачу для Project Portfolio Manager. Еще один продукт, с которым интегрируется Project Portfolio Manager — HPE Agile Manager, в нем задача связывается с User story. Таким образом, назначив задачу в Project Portfolio Manager, мы можем указать, что эта задача будет реализовываться по гибкой методологии в Agile Manager, то есть интегрируем их, и в результате все User story Agile Manager отображаются в Project Portfolio Manager.
Следующий этап — разработка. Можно использовать абсолютно любую среду разработки — Visual Studio, Eclipse и т.д. Все эти продукты тоже интегрируются с Agile Manager и имеют доступ к User Story. Разработчик в привычной среде получает уведомления из Agile Manager о назначении ему той или иной User Story, после чего принимает её в работу и начинает менять программный код в соответствии с поставленной задачей. После изменения кода можно произвести контроль безопасности с помощью HPE Fortify Static Code Analyzer и при необходимости осуществить другие вспомогательные операции, а затем дать команду на выполнение последующих операций. Созданный код сохраняется в хранилище (Git или любом другом), после чего автоматически компилируется с сохранением артефактов компиляции. Одновременно происходит обновление универсальной базы данных управления конфигурациями (UCMDB), которая автоматически переходит на новую версию разрабатываемого ПО. Всем этим процессом, как правило, «руководит» Jenkins или другой Continuous Integration Tool — интеграционная платформа, обеспечивающая непрерывность процессов разработки программного обеспечения.
Далее Jenkins готовит среды для тестирования. Здесь можно использовать HPE Codar, VMware, Docker или другие продукты. Наиболее распространены статичные тестовые контуры, в которые изменения вносятся в автоматическом режиме. При необходимости тестовые среды — как физические, так и виртуальные либо смешанные — могут быть созданы полностью «с нуля». Именно на этом этапе удается избежать той самой трети конфигурационных ошибок, возникающих при выполнении этой процедуры в ручном режиме. В тестовые среды встраивается мониторинг, позволяющий как можно раньше выявить возможные ошибки. В дальнейшем скрипты мониторинга будут применены и в промышленной среде.
После развертывания тестовой среды, Jenkins запускает процедуру автоматического тестирования: функциональные, нагрузочные, производительные, интеграционные, регрессионные или другие виды тестов. В случае их успешного прохождения на всех контурах код автоматически разворачивается на промышленной среде и в последний раз проверяется на работоспособность.
По словам многих заказчиков, ценность описанного подхода состоит в том, что он позволяет получить полную картину модели разработки — с участием абсолютно всех заинтересованных сторон, с четко обозначенными процессами и интеграционными механизмами. В заключение следует подчеркнуть, что стратегия Hewlett Packard Enterprise по отношению к DevOps подразумевает использование не только продуктов HPE, но и любых других решений, ведь главное, как уже говорилось выше, отнюдь не технологии, а люди и процессы.
Автор: Hewlett Packard Enterprise
