Создание приложений — сложный процесс, включающий несколько элементов: написание кода, тестирование, исправление ошибок, тестирование и, наконец, запуск в производство.
Можно сказать, что в этом процессе участвуют три независимых «государства» — разработчики, тестировщики и сотрудники отдела эксплуатации.
Каждая из этих групп выполняет свои задачи и использует разные критерии оценки эффективности своей работы.
Для разработчиков это скорость написания и количество функций, реализованных в программном коде; для тестировщиков – количество выявленных ошибок; для оперативного отдела стабильность систем и минимальное количество инцидентов.
Такая модель работы часто приводит к конфликту интересов: первые стараются как можно быстрее написать код и отправить его на проверку, вторые готовы проверять и тестировать столько времени, сколько необходимо, чтобы выявить все ошибки, и третий испытывает трудности с принятием кода, поскольку любые изменения влекут за собой потенциальные риски для всей ИТ-инфраструктуры.
В результате весь процесс создания приложений растягивается на длительный срок, что, учитывая сложную экономическую ситуацию, совершенно неприемлемо, ведь бизнес должен быть максимально гибким и клиентоориентированным, выпускать новые продукты и услуги в своевременно.
Конечно, многие компании уже давно осознали неэффективность такой модели выпуска приложений и начали искать пути ее оптимизации.
Одним из таких методов является модель 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 имеет неоспоримое преимущество: максимальное снижение рисков при развертывании за счет автоматизации всех процессов.
При разработке по модели «Водопад» примерно треть всех ошибок вызвана человеческим фактором: люди допускают ошибки при внесении изменений, при подготовке инфраструктуры и т. д. Чаще всего эти ошибки возникают из-за того, что разные отделы, занимающиеся созданием ПО, не есть общие инструменты и нет возможности поделиться полученными знаниями.
Еще один важный момент – размывание ответственности, когда каждый специалист отвечает только за свою узкую область.
Теперь немного о том, как реализована поддержка продуктов DevOps. Планирование изменений сначала происходит в HPE Project Portfolio Manager и Service Manager. Сюда входят потребности и запросы, о которых сообщает бизнес.
Кроме того, с помощью Service Manager отдел эксплуатации может сообщить, какие изменения кода необходимо внести для разрешения конкретного инцидента, и эти изменения немедленно преобразуются в задачу для Project Portfolio Manager. Еще один продукт, с которым интегрируется Project Portfolio Manager, — это HPE Agile Manager, в котором задача связана с историей пользователя.
Таким образом, назначая задачу Project Portfolio Manager, мы можем указать, что эта задача будет реализована по гибкой методологии в Agile Manager, то есть мы их интегрируем, и в результате все пользовательские истории Agile Manager отображаются в Project Portfolio. Менеджер.
Следующий этап – развитие.
Вы можете использовать абсолютно любую среду разработки — Visual Studio, Eclipse и т. д. Все эти продукты также интегрируются с Agile Manager и имеют доступ к User Story. Разработчик в привычной среде получает уведомления от Agile Manager о назначении той или иной User Story, после чего принимает ее в работу и начинает изменять программный код в соответствии с задачей.
После изменения кода вы можете выполнять мониторинг безопасности с помощью HPE Fortify Static Code Analyzer и выполнять другие вспомогательные операции по мере необходимости, а затем управлять последующими операциями.
Сгенерированный код сохраняется в репозитории (Git или любом другом), после чего автоматически компилируется с сохранением артефактов компиляции.
При этом обновляется универсальная база данных управления конфигурациями (UCMDB), которая автоматически переходит на новую версию разрабатываемого программного обеспечения.
Всем этим процессом обычно «управляет» Jenkins или другой инструмент непрерывной интеграции — интеграционная платформа, обеспечивающая непрерывность процессов разработки программного обеспечения.
Далее Дженкинс готовит среду для тестирования.
Здесь вы можете использовать HPE Codar, VMware, Docker или другие продукты.
Наиболее распространены схемы статических испытаний, в которых изменения вносятся автоматически.
При необходимости тестовые среды – как физические, так и виртуальные или смешанные – могут быть созданы полностью с нуля.
Именно на этом этапе можно избежать той самой трети ошибок настройки, которые возникают при выполнении данной процедуры вручную.
Мониторинг встроен в тестовые среды, чтобы помочь выявить возможные ошибки как можно раньше.
В будущем скрипты мониторинга будут использоваться в промышленной среде.
После развертывания тестовой среды Jenkins запускает процедуру автоматизированного тестирования: функционального, нагрузочного, производительного, интеграционного, регрессионного или других типов тестов.
Если они проходят успешно на всех контурах, код автоматически развертывается в производственной среде и в последний раз проверяется на работоспособность.
По мнению многих заказчиков, ценность описанного подхода в том, что он позволяет получить полное представление о модели разработки — с участием абсолютно всех заинтересованных сторон, с четко прописанными процессами и механизмами интеграции.
В заключение следует подчеркнуть, что стратегия Hewlett Packard Enterprise в отношении DevOps предполагает использование не только продуктов HPE, но и любых других решений, ведь главное, как говорилось выше, не технологии, а люди и процессы.
.
Теги: #программирование #разработка #DevOps #hpe
-
Развитие Бизнеса В Стартапах
19 Oct, 24 -
Как Стать Специалистом По Данным В 2019 Году
19 Oct, 24 -
Фрилансим: Перезагрузка
19 Oct, 24
