Проблемы, связанные с релизами it-продуктов на микросервисной архитектуре
Конечно, микросервисная архитектура - это не серебряная пуля. Как и все в этом мире, она имеет свою долю недостатков и ограничений. В этой статье я опущу технические аспекты и сосредоточусь только на проблемах, связанных с управлением релизами it-продуктов на микросервисной архитектуре. С этой точки зрения я хотел бы выделить следующие проблемы:
- Частые релизы. По своей природе архитектура микросервисов вынуждает нас выпускать релизы чаще, чтобы обеспечить быструю и детализированную поставку нашим клиентам. Вместо одного релиза монолитного решения мы будем выпускать несколько небольших релизов нескольких микросервисов. С точки зрения управления релизами это создает накладные расходы на планирование, отслеживание прогресса и интеграцию. Ситуация станет еще хуже, если учесть тот факт, что у каждого сервиса свой цикл выпуска.
- Вариативный процесс разработки. Scrum, Kanban или что-то другое? Нет проблем. Микросервисная архитектура позволяет командам выбирать свой собственный процесс разработки без необходимости согласовывать его с другими командами. Это, безусловно, хорошо для команд разработчиков, но может стать кошмаром для менеджера продукта или менеджера релиза ( PO /RM), которому необходимо создать единый план для всего решения.
- Зависимости между релизами микросервисов. Для реализации определенной бизнес-функции необходимо выпустить все версии соответствующих микросервисов. Такой подход влечет за собой гораздо большие управленческие расходы по сравнению с выпуском только одной версии монолитного решения. PO/RM приходится объединять эти версии в консолидированный план, чтобы ответить на вопрос «Когда будет предоставлена функциональность?», а не просто знать дату релиза монолита. Задержка любой версии приведет к общей задержке всего процесса поставки. Поэтому у PM/RM должен быть простой способ интегрировать несколько версий в единый пакет поставки и отслеживать, был ли он поставлен в соответствии с планом.
- Интеграционное тестирование end to end. Этот пункт особенно актуален для корпоративных B2B-решений с рядом запрошенных клиентом кастомизаций. Все решение должно быть настроено специально для каждого клиента и протестировано после того, как функциональность будет реализована в каждом конкретном микросервисе. Для этого PO/RM должен иметь представление о последней стабильной версии каждого микросервиса, иметь представление о том, какие версии развернуты и в каком окружении (пул окружений или контейнеры в определенной конфигурации), а также координировать тестирование и приемку.
В Jira есть встроенные версии и функциональность отслеживания прогресса. Но, принимая во внимание вышеупомянутые проблемы, существуют открытые вопросы для построения эффективного релизного процесса микросервисов:
- Невозможно определить рабочий процесс версии, поэтому невозможно понять, на какой стадии находится версия. Например, все функциональные требования могут быть выполнены, но версия микросервиса должна пройти нагрузочное тестирование перед развертыванием в производственной среде.
- Скорее всего, различные команды, разрабатывающие микросервисы, будут работать по своему собственному workflow в Jira, чтобы иметь возможность гибко организовать свой собственный процесс разработки. Из коробки Jira не имеет удобной функциональности для визуализации и отслеживания версий из нескольких продуктов в одном месте.
- Кроме того, было бы выгодно объединить несколько версий микросервисов в один релиз, который будет представлять желаемую бизнес-функциональность во всех сервисах.
- Релиз может иметь свой собственный workflow. Например, перед внедрением в производство может потребоваться сквозное тестирование, даже после принятия клиентом B2B.
Инструменты для управления релизом
Видно, что Jira обладает большой гибкостью и позволяет устранить эти ограничения различными и эффективными способами: используя встроенные возможности или расширяя их с помощью сторонних приложений.
Вы можете обратиться к этой полезной статье о том, как настроить workflow управления релизами с помощью стандартной функциональности.
Альтернативный способ организации управления релизами микросервисов предлагает приложение Release management (Release management для Jira Cloud).
Определим контекст
Представим себе организацию с 5 командами, которые работают над своими собственными микросервисами:
Схема 5 команд, работающих над it-продуктом с микросервисной архитектурой Каждый микросервис имеет свой собственный релизный цикл, который не синхронизирован с релизными циклами других микросервисов. Обычно каждая конкретная Пользовательская история (от англ. User story - формат описания задачи на новый функционал для команды разработки) требует внесения изменений в несколько микросервисов.
Давайте рассмотрим, как приложение Release management может упростить управление релизными циклами микросервисов.
Визуализация версий различных сервисов на доске
Одно из правил Kanban гласит: «Визуализируйте поток». Это правило - очень важная концепция, поскольку большинство людей на Земле - визуалы, поэтому они лучше воспринимают визуальное представление информации. В приложении Release Management можно импортировать версии из нескольких сервисов и визуализировать их на доске. Из коробки Jira имеет два статуса версий: Releases и Unreleased. Приложение Releases Management расширяет эту возможность за счет пользовательского workflow версий. Workflow легко интегрируется со встроенными статусами версий.
Kanban доска в Jira для визуализации версий Особое преимущество, о котором я хотел бы рассказать, - это возможность перетаскивать версии из одного столбца в другой на одной доске, так что менеджеру релиза не нужно перескакивать между разными страницами веб-интерфейса, чтобы обновить несколько распределенных версий.
Создание многоверсионного релиза
Хотя хорошо, когда все версии из нескольких сервисов визуализируются на одной доске, запоминать и держать в голове, какие именно версии должны быть выпущены для реализации той или иной User story, не надежно и слишком рискованно.
Чтобы решить эту проблему, в приложении была введена сущность Release. Release может состоять из нескольких версий. При этом каждая версия может не принадлежать, принадлежать одному или нескольким релизам.
В нашем примере мы можем объединить все версии, которые должны быть поставлены для расширения китайского рынка, в один Release и отслеживать их вместе.
Kanban доска в Jira для визуализации релиза, нацеленного на расширение Китайского рынка Кроме того, сущность Release может иметь свой собственный workflow для визуализации деятельности, связанной с поставкой User story, например, включающий в себя статусы: интеграционное тестирование, тестирование производительности или приемочноое тестирование.
Кастомный workflow для Release в Jira Построение временной шкалы
Управление релизами - это не только статусы, но и точное знание того, когда будет готова та или иная версия. Представление в виде Timeline - идеальное решение для этой цели. Кроме того, оно хорошо подходит для создания отчетов.
Timeline релизов в Jira API и интеграция с CI
Непрерывная доставка (от англ. Continuous delivery) - это все об автоматизации. В идеальном мире инструмент управления релизами должен быть интегрирован с сервером непрерывной интеграции, чтобы автоматически обновлять статусы версий после каждого развертывания.
Приложение Release Management имеет мощный REST API, который позволяет легко интегрироваться с CI-сервером с помощью webhooks. Это значительно сократит объем ручной работы и накладные расходы менеджеров.
Заключение
Микросервисная архитектура - это мощная технология разработки программного обеспечения, отвечающая требованиям современного рынка. Она позволяет решать проблемы масштабируемости, надежности и качества, а также значительно сокращать время выхода на рынок, что крайне важно для высококонкурентных рынков.
Чтобы в полной мере использовать преимущества микросервисной архитектуры, нам необходимо снизить управленческие накладные расходы, которые естественным образом возникают в гранулированной и распределенной системе (в отличие от монолита).
Приложение Release Management помогает устранить накладные расходы, автоматизировать рутинные операции и создать единое рабочее пространство для RM/PO. Кроме того, оно обеспечивает лучшую видимость и делает управление сложными, многокомпонентными релизами простым и понятным.