Agile и DevOps позволяют быстрее реализовывать задачи разработки для достижения бизнесовых показателей, поставлять на рынок востребованные и актуальные цифровые продукты.
Направление DevOps возникло 17 лет назад на фоне нарастающих проблем в традиционной модели разработки ПО. В России массовое распространение началось с 2015-2016 гг.
Растущий спрос на методологию DevOps в связке с Agile, на мой взгляд, продиктован растущим спросом на микросервисную архитектуру цифровых решений. Бизнес понял: чтобы зарабатывать больше и быстрее необходимо больше производить различных цифровых продуктов и при этом тратить на это меньше ресурсов. Возникла потребность автоматизировать и ускорить все этапы производственной цепи.
До момента популяризации микросервисов реальной потребности выделять отдельного специалиста на разворачивание инфраструктуры не было. Разработчики могли сами писать скрипты CI/CD. В современных условиях, когда микросервисные архитектуры все чаще используются при проектировании масштабных цифровых решений, сотни микросервисов могут обновляться по нескольку раз в день и без автоматизации и DevOps-инженера здесь уже не получится обойтись.
Культура непрерывной интеграции и непрерывной доставки базируется на гибких методологиях разработки Agile и DevOps. Они позволяют быстрее реализовывать задачи разработки для достижения бизнесовых показателей, поставлять на рынок востребованные и актуальные цифровые продукты.
Agile и DevOps тесно взаимосвязаны. Методология Agile отвечает за разработку продукта. DevOps-технология является частью Agile и сосредоточена на автоматизации различных рутинных процессов. Вместе они позволяют в кратчайшие сроки подготавливать новые версии цифровых решений. Разработчикам остается только писать код, а метология DevOps автоматизирует сборку кода, обеспечивает автоматическое разворачивание и мониторинг поведения кода в цифровой среде, проводит оценку инфраструктурных и бизнес-метрик.
Если кратко, DevOps позволяет разработчикам быстро и надежно передавать код в продакшн.
Преимущество культуры CI/CD очевидно: в условиях сжатых временных сроков спринта необходимо разрабатывать и тестировать код, отслеживать как он работает в связке с другими сервисами. Отсюда вытекает естественное разбиение среды на различные стенды: стенд разработчиков, стенд тестировщиков и демо-стенд, который ничем не отличается от продакшн-среды, кроме данных. Любой разработанный код проходит все три стенда и, если всё хорошо, то разработки уходят в продакшн. Такой производственный процесс значительно ускорил и качественно улучшил выпуск релизов.
Пример из практики DevOps-направления IRLIX.
Цифровой продукт - система электронного документооборота. До внедрения культуры CI/CD у клиента все сборки и релизы продукта проходили вручную, силами разработчиков. По длительности могли занимать целый день.
Постоянными проблемами были сложности с откаткой опубликованного релиза, передачей его со стенда на стенд. Приложение находилось в монорепозитории, но предполагалось, что это микросервисы (или просто сервисы), с API gateway.
Опытный DevOps-инженер из нашей команды смог за 10 месяцев внедрить в производственный процесс методологию контейнеризации, перевести все на расширяемую платформу с открытым исходным кодом - kubernetes, и выстроить процесс CI/CD. Подготовить несколько стендов, на которых происходят развертывание и запуск продукта в кластере, что полностью освободило разработчиков от рутинных задач сборки и деплоя, сделало процесс быстрым, прозрачным и приятным. Кроме того, был отработан процесс “отката” продукта на предыдущую версию, что уменьшило время простоя в случае ошибок в приложении.
Для закрытия бизнес-потребности клиента по подготовке цифрового решения к выпуску на рынок, мы сделали "коробку" с kubernetes и сервисами внутри, достаточно простую для установки и эксплуатации.
У каждого из внешних заказчиков продукта нашего клиента был свой закрытый контур. Поэтому обновления системы проводилось не средствами CI/CD, а выкачивалось с помощью того же инструмента, которым производилась установка. Это было очень сложно и неудобно. Применение культуры непрерывной интеграции и непрерывной доставки на этом этапе позволило сделать процесс обновления системы электронного документооборота практические бесшовным, а для конечных пользователей процесс обновления стал проходить совершенно незаметно.
В результате нескольких месяцев реальной эксплуатации культуры...