Релизный процесс что такое
Управлять релизом просто: правила и этапы release management
Релиз является одним из самых важных и ожидаемых событий в жизненном цикле продукта. Приготовления к релизу могут занимать много усилий и времени, участия всей команды и заинтересованных сторон. Хорошо, если выпуск продукта или его версии проходит гладко и становится настоящим праздником. Но бывает иначе. Что из себя представляет эффективный релиз-менеджмент и как менеджерам продукта научиться его секретам?
Релиз связан с запуском нового продукта/сервиса/услуги или набором новых функций, изменений, которые становятся доступны клиентам или пользователям и обеспечивают новую продуктовую ценность.
Часто релиз состоит из ряда решений по устранению проблем и улучшений предоставляемых услуг, может включать изменения в ПО. На самом деле, это довольно значимое событие как для внутренних команд, так и для целевой аудитории.
Управление релизами помогает командам планировать свою работу и видеть конечный результат, а для клиентов это, своего рода, гарантия качества и получения новой ценности.
Хорошо подготовленный релиз — это не только предоставление доступа к новым техническим возможностям продукта. Это конечная дата, когда ваша команда может предоставить новый пользовательский опыт, поддержать и развить взаимодействие с ним.
Релизы должны включать все дополнительные задачи и активности, такие, например, как обновления на официальном сайте и в социальных сетях, обучение команды поддержки, обновление всех маркетинговых материалов и т. д.
Основная цель управления релизом — создавать, тестировать и доставлять новые возможности, которые будут удовлетворять все продуктовые требования и намеченные цели.
Продуктовым командам стоит тщательно планировать релизы, поскольку они являются новым предложением, которое ожидают клиенты.
Что включает процесс управления релизом?
Понимание процесса управления выпуском продукта может отличаться у разработчиков и нетехнических специалистов. Важно учитывать все аспекты релиза и прислушиваться к мнению каждого члена команды.
Процесс управления релизом может включать следующие этапы:
В управлении релизом продукта могут участвовать практически все члены команды.
Product manager и Project Manager
Менеджеры продуктов и менеджеры проектов несут основную ответственность за релиз. Функционал product manager project и manager отличается, но миссия у них одна — выпустить продукт и представить его клиентам в идеальном виде.
Разбработчики
Команда разработки — это ключевые игроки в управлении релизом, поскольку они участвуют в большинстве процессов в жизненном цикле продукта. Они оценивают изначальные затраты и время, определяют основные требования, создают документацию и разрабатывают функциональность. Они принимают главные решения о том, что можно сделать и что не нужно, а также сколько времени это займет.
Маркетинг
Маркетологи всегда должны “держать руку на пульсе” и быть в курсе того, чем живут конкуренты. В управлении релизом им важно тесно отрудничать с sales-менеджерами для получения новых и удержания существующих клиентов.
Тестировщики
Тестировщики работают вместе с разработчиками. Их задача — тестировать результаты исследований и разработки, основываясь на установленных критериях. Продукт не придет к релизу, пока не будут учтены все замечания и критерии прохождения тестирований.
Служба поддержки
Support-команда или отдельный специалист поддержки первыми получают сообщения, елси что-то пошло не так. Они должны понимать и знать все о релизе и должны быть должным образом подготовлены на всех уровнях еще на стадии планирования.
Помимо этих основных ролей, к управлению релизом могут привлекаться и другие специалисты: отдела закупок, финансисты, sales, биллинг, system engineering и др.
Почему нужно внедрять процесса управления релизам?
Что такое Release Notes в процессе управления релизом?
Release Notes — это примечания к версии продукта, в которых описываются изменения между выпускаемой и предыдущей версиями этого продукта. Такой документ может составляться для пользователей и для внутренних команд: тестировщиков, маркетологов, службы поддержки.
Когда используются примечания к релизу?
Примечания к релизу распространяются вместе с продуктами. Иногда — когда продукты все еще находятся в разработке или тестировании. Документ может быть доставлен клиентам при выпуске обновления (для продуктов, которые уже были использованы клиентами).
Вы можете найти различные варианты написания Release Notes, поскольку для этого документа нет единого стандарта или формата. В разных компаниях менеджеры продуктов, тестировщики и разработчики, которые обычно ответственны за написание примечаний, обычно используют свои собственные шаблоны.
Вот как выглядит страница с примечаниями к релизу у Firefox:
Как писать примечания к релизу?
Содержание документа зависит от типа релиза. Вот пример основных пунктов:
Заключение
Управление релизом во многих компаниях становится отдельным самостоятельным процессом, который сообщает заказчику дату выпуска продукта и основные этапы его развития. Заказчик участвует в приоритизации и вовлечен в определение содержания релиза.
Процесс позволяет менеджерам продуктов и команде своевременно оценить загрузку и управлять объемом работ, доставлять изменения в срок. Управление релизами позволяет собирать собственную статистику, с которой удобнее в дальнейшем обосновывать запросы на дополнительные ресурсы.
Если вы хотите детальнее разобраться в теме release management и отыскать интересные инсайты разных компаний, следующие книги будут полезными: (на английском языке)
Всë, что вам нужно знать об управлении релизами
В постоянно меняющемся, эволюционирующем мире приложений отдавать полусырые релизы пользователям — не вариант. Именно здесь на первый план выходит управление релизом. Данный материал от одного из менеджеров компании Hike, рассказывает о трейн-релизах и о стратегии ветвления, вводя в курс дела тех, кто хочет расширить свою зону компетенции и получить представление об управлении проектом.
Что это такое управление релизом?
Управление релизами охватывает все этапы выпуска программного обеспечения, от разработки и тестирования до развертывания. Управление релизом требуется каждый раз, когда запрашивается новый продукт, или даже изменения в продукт существующий. Есть пять основных шагов по управления релизом, которые мы делаем в этой ситуации:
Планирование релиза
Этап планирования в большинстве случаев интенсивен, так как именно на этом этапе весь наш релиз организуется от начала до конца. Надёжный план релиза помогает придерживаться верного пути и обеспечивать надлежащее соблюдение стандартов и требований.
При планировании релизов мы считаем, что разработанные несколькими командами приложения нуждаются в согласованном подходе, который должен быть выпущен заранее. Именно здесь в игру вступает концепция «трейн-релиза». Следуя подходу трейн-релиза, команды могут планировать изменения на основе релизов и отправлять их в Play Store.
Самым первым шагом, ещё до того, как мы начнём реализовывать трейн-релиз, является определение временных интервалов каждого этапа. В нашем случае этап разработки — это две недели. Затем нужно определить, сколько времени вы хотите потратить на интеграционное тестирование и этапы развёртывания. Ниже наш пример интервалов:
Следующий шаг на пути к релизам — создание рабочего процесса, к которому на протяжении всего релиза могут обращаться как наши команды, так и ключевые заинтересованные стороны.
Рабочий процесс сразу объясняет, как устроен весь релиз и какую роль играет каждый член команды. Мы используем инструмент «Асана» для отображения этих деталей, перечисленных ниже:
Как только план утверждается и окончательно оформляется, начинается самое интересное!
Важные аспекты планирования релизов
Создание и использование трейн-релиза звучит здорово, но поддерживать процесс в рабочем состоянии во время планирования трейн-релиза может быть непростым. Вот некоторые детали этого процесса:
Построение релиза
После того как план выпуска готов, можно приступать к тестированию продукта для релиза. Это будет фактическое «тестирование уровня пользователя» продукта на основе изложенных в плане выпуска требований.
В определённый день и время (скажем, в понедельник, в 15:00) происходит замораживание/отсечение кода. До этого момента команды успевают посмотреть, протестировать и смержить фичи в ветку разработки, которая должна быть частью трейн-релиза. В 15:00 релиз-менеджер создаст из ветки разработки ветку релиза. Этот шаг автоматизирован с помощью Jenkins.
Автоматизируя переход ветки, мы проверяем все пороговые значения производительности, бенчмарк и автоматизации из предыдущих релизов в маркет устанавливаются на текущий как основание сравнения, а трейн-релиз блокируется от дальнейших изменений.
Как только код замораживается, начинается новый цикл разработки, и все участвующие команды начинают новый спринт и продолжают разработку. Самое замечательное в трейн-релизе: все знают о следующем, запланированном релизе, и это помогает людям соответствующим образом планировать свою работу.
Релиз веток и контроль версий
Разработка продукта обычно не останавливается, когда заканчивается разработка для релиза, поэтому первое, о чем мы думаем, это как заморозить тестируемую сборку и в то же время поработать над новыми возможностями для следующего релиза. Что случится, если в сборке релизов появится ошибка? Как исправить ошибку, если вы уже добавили кучу новых вещей до того, как эта ошибка нашлась?
Именно здесь на помощь приходит хитрая стратегия ветвления, в которой есть концепция разветвления. Как следует из названия, ветвление кода означает, что точно так же, как у веток дерева, код веток до определенной точки совпадает, а затем разбивается на две копии.
Каждая ветвь может развиваться независимо от другой. В этом случае одна копия — ветка релиза — остаётся замороженной на том месте, где вы завершили разработку. Это то, что мы называем отсечённой веткой. Другая ветка (ветка разработки) может быть изменена новым кодом и исправлениями ошибок, не затрагивая ветку релиза вообще. Если ошибка найдена в релиз-кандидате, исправление может быть разработано и добавлено в ветку релиза. Таким образом, следующая сборка, которую вы снова соберёте из ветки выпуска, может быть идентична первой, за исключением исправления одной ошибки. Таким образом, вы можете минимизировать риск появления новых ошибок в выпуске и изолировать баги от нового кода. Исправление также применяется к ветке разработки, чтобы гарантировать, что та же самая ошибка не попадёт в следующий релиз. Другое преимущество релиз-ветвления состоит в том, что как только вы действительно публикуете код, у вас есть «замороженная» ветка, которая представляет собой точную копию опубликованной кодовой базы. Вы можете вернуться к этому коду в любое время для справки.
Пользовательское приемочное тестирование
Пользовательское приемочное тестирование является наиболее важным шагом для управления релизом из-за объема собранных данных и исправлений, необходимых для того, чтобы сделать сборку именно такой, какой она должна быть для официального запуска.
Как следует из названия, когда речь идёт об этом виде тестирования, ключевая фигура — пользователь. Пользователи — это именно те люди, которые будут пользоваться приложением. Поэтому крайне важно сделать пользователей частью всей стратегии обеспечения качества в процессе разработки программного обеспечения. Вот где пригодится UAT. Этот тип тестирования, как никакой другой, ставит потребности пользователей в центр работы над продуктом. Вот некоторые из вопросов, на которые такое тестирование пытается ответить:
Pro Tip: всегда включайте внутреннее тестирование в планирование UAT!
Одним из способов ускорить UAT релиза для нас было использование внутренних тестовых треков, предоставляемых Google. Это помогает нам быстрее распространять тикеты среди коллег и фиксировать их отзывы посредством автоматического создания тикетов JIRA. Перед отправкой финального теста команда также следит за тем, чтобы отзывы были учтены.
Подготовка и релиз
Этот шаг заключается в том, чтобы внести последние штрихи в продукт, учитывая все, что было понято при UAT. Подготовка релиза также включает в себя заключительную проверку качества командой по контролю качества. В ходе проверки группа по контролю качества проводит окончательные проверки, чтобы убедиться, что сборка соответствует минимальным стандартам приемки и бизнес-требованиям из плана релиза.
После завершения ревью релиз-группа завершит релиз для начала развертывания. Перед тем, как сборка может быть развернуто в живой среде, она должно быть утверждена соответствующими ответственными командами, такими как команда дизайна. UAT гарантирует, что результат утверждается до передачи на следующий этап.
Развертывание релиза
Наконец-то настал важный день, когда окупилась вся тяжелая работа нашей команды. Пришло время выпустить наш продукт в дикую природу продакшна. Помимо простой отправки сборки в производственную среду, стадия внедрения также содержит обучение работе с продуктом как конечного пользователя, так и компании в целом. Например, пользователи должны быть уведомлены об изменениях в релизе, и именно здесь на появляется в поле зрения «What’s New» (Что нового). У нас есть автоматизированный процесс на Jenkins, содержащий такие шаги:
В данном случае мы начинаем с развертывания для 1%. На каждом этапе необходимо следить за ревью, а также за инструментами мониторинга падений релиза, чтобы выявить возможные проблемы.
Если ошибка становится заметной в 1%, у команды есть шанс отреагировать на проблему и решить, нужно ли исправлять ее быстро. Если это так, то трейн-релиз не должен достигнуть следующего шага развертывания в 5%. Вместо этого проблема решается для 1% пользователей. Как только проблема устраняется и решение проверено, трейн-релиз может перейти на стадию 5%.
Как и в простой версии трейн-релиза, только релиз-инженер или команда релиза заботится о процессе релиза после замораживания кода. Все остальные команды продолжают «нормальную» разработку.
Анализ после релиза
Работа по управлению релизом не заканчивается, когда публикуется код, продолжаясь до тех пор, пока вы не будете готовы выпустить релиз снова. Если вы хотите, чтобы ваше приложение было успешным, ему нужно хорошее ревью, вам также нужно следить за релизом в производственной среде, чтобы исправлять ошибки, внедрять функции, которые нужны людям, и решать проблемы пользователей. Для этого мы используем Firebase Crashlytics, где отслеживаем любые сбои, требующие немедленного исправления.
Кроме того, ревью приложения дают представление о вашем продукте, которое гораздо труднее получить при других подходах. И Google Play, и App Store предоставляют разработчикам приложений возможность отвечать на отзывы, что может быть невероятно полезным инструментом для получения дополнительной информации о проблемах с приложением от пользователей. Отзывы могут выявить проблемы, с которыми сталкиваются пользователи при работе с вашим приложением, и проинформировать о будущих изменениях.
Подведем итоги
Управление релизами наблюдает за чрезвычайно динамичным процессом. Каждый релиз — это возможность уточнить всё — от нашего рабочего процесса до нашего контрольного списка, поскольку мы вместе с ним обнаруживаем области улучшения. Вот некоторые преимущества, которые мы получили:
Мы также увидели, что наш процесс управления релизами облегчил сотрудникам по всем направлениям — от разработчиков и владельцев продуктов до руководителей — просмотр плана высокого уровня и получение краткой информации о своём прогрессе, работа синхронизирована.
Корпоративный Release Manager: муки и радости
Автоматизация процессов разработки и тестирования программного обеспечения (ПО) — лучший способ уйти от рутины и заняться действительно интересными задачами. Азарт от реализации новой функции может быть погребен под рутиной сборки, подготовки и выпуска нового релиза. Как избежать этой неизбежной скучной задачи, но выпустить релиз ПО, не упустив при этом ни одной мелочи при его подготовке?
Выпуск релиза ПО — это не только сборка ПО в определённого формата пакет и отправка пакета на место его установки. Зачастую выпуск релиза включает в себя множество других задач, таких как:
оформление сопроводительной документации;
указание номера версии релиза у задач в Bug-трекинге;
проверка, что нужные задачи попали в нужный релиз;
оформление и рассылка уведомлений о выходе релиза.
Количество таких задач может меняться от проекта к проекту в зависимости от требований и рабочего процесса, принятого на проекте.
Но независимо от количества и типа задач, практически для любого продукта выпуск релиза происходит с определённой периодичностью. И такой процесс — это отличный кандидат для автоматизации рутинных действий.
Логично будет использовать уже существующие инструменты. И часть процесса выпуска релиза на нашем проекте уже была автоматизирована. Но оставалось ещё много работы, которую приходилось выполнять вручную. И желание автоматизировать этот процесс привело к тому, что у нас появился сервис позволяющий выпустить релиз в два клика. И сегодня я расскажу, как мы пришли к созданию такого инструмента и каких результатов достигли.
С небольшого ручейка начинается река
Изначально не было цели создать инструмент автоматизации выпуска релизов. У нас был процесс выпуска релизов, он хорошо и пошагово расписан на Wiki. Но один из шагов был настоящей мукой для выпускающего релиз разработчика. А именно: добавление информации о выпуске релиза на страницу Wiki.
Этот нехитрый шаг требовал усидчивости, внимания и кропотливой ручной работы при написании статьи о выпуске релиза. Большая часть работы сводилась к копированию информации из задач в Bug-трекинге в страницу релиза на Wiki. На это несложное, но жутко скучное и однообразное действие требовались не только моральные силы разработчика, но и время.
Поэтому создание инструмента автоматизации выпуска релизов начинался с довольно простой консольной программы, которая через API Bug-трекинга вытаскивала необходимый список задач и формировала страницу в Wiki-разметке. И по завершении работы программы готовая страничка быстро и заботливо переносилась разработчиком уже на Wiki.
Сэкономив время на одном шаге выпуска релиза, сразу возникло желание автоматизировать и другие. Результатом проделанной работы был набор скриптов, объединённый одной кодовой базой.
Муки выбора
У получившегося набора скриптов автоматизации было несколько недостатков:
скрипт надо было запускать на локальном компьютере разработчика;
сложно было выполнить проверки:
можно ли выпускать релиз?
корректно ли выпустился релиз?
Первая трудность хорошо решалась при помощи инструмента continuous integration (CI). Нужно было просто добавить шаг в сборку проекта. Но CI, к сожалению, не мог решить вторую проблему.
Зачем нужны эти проверки?
К сожалению, в активном ритме проекта бывают различные ситуации. Например, забыли перевести задачу в нужное состояние, хотя код уже попал в релизную ветку. Возможна и обратная ситуация, когда задача в нужном состоянии, а коммит забыли перенести в релизную ветку.
Нахождение таких несоответствий можно легко запрограммировать, а вот научить программу принимать решения исходя из сложившийся ситуации очень сложно. И такое решение должен принять человек, который выпускает релиз.
И по этой причине было принято решение разработать собственный инструмент, заточенный под наши нужды.
Выпуск релиза в два клика
Во время выпуска релиза необходимо выполнить две проверки:
можно ли выпускать релиз?
корректно ли выпущен релиз?
По этой причине весь процесс автоматизированного выпуска релиза был разделён на две большие части:
подготовка предрелизной информации;
выпуск релиза и отображение результатов выпуска.
1. Подготовка предрелизной информации
Всё взаимодействие с Release Manager осуществляется через веб-интерфейс. Поэтому сотруднику выпускающий релиз необходимо перейти на главную страницу Release Manager в браузере и первым кликом выбрать нужный проект. Через пару секунд Release Manager отобразит информацию о предстоящем релизе:
В таблице “Correct state” отображаются задачи, которые прошли под все необходимые критерии для включения их в указанный релиз. Иными словами, задачи в этом столбце гарантированно пойдут в релиз.
В таблице “Incorrect state” отображаются задачи, которые по каким-то критериям не подошли для включения в релиз. Все критерии разделены в две большие группы:
Resolved/Unresolved (Завершённые по статусу в Bug-трекинге/ Не завершённые по статусу в Bug-трекинге);
Merged/Unmerged (Слиты изменения по задаче в source branch/ Не слиты изменения по задаче в source branch).
Виджет “Release Options” отображает версию выпускаемого релиза, которую RM высчитывает по определённому алгоритму, и дополнительные опции, которые можно указать при выпуске релиза:
source branch — это имя ветки, на основе которой выполнялись необходимые вычисления;
Кнопка “Release!” запускает следующий шаг выпуск релиза или релиз кандидата, если активирован переключатель “RC mode”.
Имея всю информацию перед глазами, сотруднику нужно лишь проверить:
версия, указанная в задаче на выпуск релиза, совпадает с версией, подсчитанной Release Manager;
что все необходимые задачи включены в табличку “Correct state”.
Далее выставить переключатели в нужные состояния (зависит от того, что сотрудник выпускает релиз кандидат или релиз) и затем нажать кнопку “Release!”
2. Выпуск релиза и отображение результатов выпуска
В среднем Release Manager требуется несколько секунд, чтобы проделать весь объём работы, который у сотрудника при ручном выпуске релиза занимал до нескольких часов нудной и кропотливой работы. По окончанию выпуска релиза Release Manager отобразит страницу с результатами выпуска:
Всё что останется сделать — это скопировать информацию на wiki и отправить письмо с шаблоном.
Релиз Release Manager’а
Изначально Release Manager был реализован для одного проекта. И сразу стал незаменимым инструментом в работе. Но оказалось, что у ребят из других групп разработки тоже есть желание автоматизировать выпуск релизов своих проектов. И демонстрация Release Manager’а коллегам показала, что он способен помочь им в процессе автоматизации выпуска релиза.
Ребята из других групп с энтузиазмом взялись за работу и в скором времени количество проектов, поддерживаемых Release Manager возросло с 1 до 9. И для других групп разработки данный инструмент стал незаменимым помощником при выпуске релизов.
Время перемен
Концепция Release Manager, выпуск релиза в два клика, прекрасно подходила для всех проектов, включённых в него. И Release Manager исправно и активно помогал нам в работе. Но со временем всё меняется. И алгоритм выпуска релиза тоже. Какие-то шаги добавлялись, какие изменялись, а какие-то и вовсе убирались. Всё это приводило к тому, код Release Manager тоже менялся. Концепция Release Manager прекрасно продолжала работать несмотря на все изменения. Но кодовая база, к сожалению, нет.
Почему такое произошло?
Изначально Release Manager разрабатывался для автоматизации процессов на одном проекте. Поэтому дизайн приложения был заточен для работы только с одним проектом. Потом добавили ещё 8. Кодовая база изменялась со временем и в какой-то момент поддерживать код стало сложно. Это стало приводить к тому, что новые доработки в один проект стали ломать существующие функции в других. Также это привело к другой трудности, а именно по коду стало сложно понять для какого проекта он используется.
Стало ясно, что необходимо обновить Release Manager, чтобы он соответствовал текущим нуждам.
Рефакторинг
Люди, делая ремонт в доме, обновляют мебель и делают перестановку. В большинстве случаев они делают не потому, что дом перестал выполнять свои функции. Просто он перестал соответствовать их нуждам. А нужды всегда разные.
Аналог такого ремонта есть и у разработчиков. Он называется рефакторинг. Release Manager продолжал исправно выполнять свои функции, но дорабатывать и поддерживать его в исправном состоянии становилось всё сложнее и сложнее. Исходя из возникших трудностей мною были составлены требования к разработке:
изменения кодовой базы для одного проекта не влияли на функциональную работоспособность другого;
глядя в код, можно было визуально определить для какого проекта он используется, не вникая в логику его работы.
Говорят, что всё новое — это хорошо забытое старое. Отчасти так произошло с обновлением Release Manager. Вдохновение пришло из опыта работы с системами CI. В таких системах вся сборка проекта сводится к набору шагов.
Такой набор шагов ещё называют пайплайн (pipeline). Выпуск релиза тоже представляет собой набор шагов. По этой причине я принял решение, научить Release Manager собирать для каждого проекта свой собственный пайплайн, а шаги для каждого проекта хранить отдельно друг от друга.
Для этой цели я создал аннотацию @Pipeline, внутри которой можно определить шаг. Шаг хранит в себе информацию о проекте и о порядке выполнения шага в наборе шагов. Шаг представляет собой аннотацию @Step. Вот пример использования:
Один и тот же шаг может быть переиспользован на разных проектах. Поэтому для аннотации @Pipeline можно указать несколько аннотаций @Step. Также один и тот же шаг в разных проектах может выполняться разным по счёту. Это уже зависит от алгоритма выпуска релиза конкретного проекта.
Благодаря аннотациям, разработчику не требуется вникать в логику работы кода, чтобы понять на каких проектах он используется. Но аннотации здесь поставлены не только для наглядности. Они используются Release Manager’ом для сборки шагов по каждому проекту в пайплайн выпуска релиза этого проекта.
Однако возникла трудность, так как проекты все разные и сами шаги тоже могут отличаться. Другими словами, реализация конкретных шагов может сильно отличаться друг от друга на разных проектах. И Release Manager должен уметь склеивать любые шаги для любого проекта. Этого можно добиться, если все шаги будут использовать единый интерфейс:
У интерфейса всего один метод, который запустит выполнения шага. По концепции Release Manager, выпуск релиза делится на два этапа:
сбор предрелизной информации;
выпуск релиза и отображение результатов.
Поэтому Release Manager’у необходимо уметь понимать какие шаги к какому этапу относятся. По этой причине было добавлено ещё два интерфейса для каждого этапа процесса выпуска релиза:
В итоге для создания одного шага выпуска релиза требуется выполнить два действия:
Создать класс, реализующий либо интерфейс PreReleaseStep, либо интерфейс ReleaseStep;
Над классом указать аннотацию @Pipeline, а в ней аннотацию @Step, содержащую имя проекта и порядок выполнения шагов.
Для начала он их отфильтрует и упорядочит для каждого проекта:
После того, как каждый шаг прошёл через фильтр, все шаги сортируются по порядку, указанному в поле order в аннотации @Step. Результат операции снова собирает в список (List).
После это Release Manager начнёт склеивать шаги в пайплайн:
В первом методе map() Release Manager создаёт LogableFunction из каждого шага и добавляет логирование перед и после выполнения шага. (О LogableFunction можно почитать здесь). В данном случае логируется, что шаг запущен и шаг завершён. Это было сделано по нескольким причинам:
разработчикам не нужно писать эти логи в каждом шаге;
единообразный стиль логирования облегчает чтение логов.
В качестве имени шага было выбрано имя класса. Но при желании можно добавить в интерфейс метод, возвращающий имя шага.
Метод reduce() склеивает шаги в одну цепочку последовательного вызова метода execute() у каждого шага. Результат выполнения метода вернёт одну функцию. На втором методе map() полученную функцию снова оборачиваем в LogableFunction и добавляем логирование о том, что выполнение пайплайна для определённого проекта началось и закончилось.
Метод также бросает исключения в определённых случаях. Если исключение будет брошено, то запуск Release Manager остановится, так как Web-сервис не может корректно предоставлять услуги по выпуску релиза, если не удалось собрать его пайплайн.
После того как все пайплайны собраны, Release Manager запущен и ожидает, когда пользователь зайдёт на главную страницу Web-сервиса и выберет проект. В этом случае Release Manager найдёт нужный сервис, содержащий необходимый пайплайн и выполнит его. В коде Release Manager’а этот процесс выглядит так:
Метод getPreReleaseInfo() принимает один аргумент. В нём содержится базовая информация о доступных для пользователя опциях при выпуске релиза. Изначально она заполнена значениями по умолчанию.
Далее создаётся объект pipelineContext, где будет хранится вся информация о ходе работы в рамках каждого шага при сборе предрелизной информации. Далее контекст кладётся в специальный объект SupplierFunctor к которому можно последовательно применять различные функции. И результат выполнения PreReleaseInfo возвращается пользователю после вызова метода get().
Код выполнения выпуска релиза очень сильно похож на код, выполняющий сбор предрелизной информации:
После проведённого рефакторинга вся бизнес-логика заключается в отдельных шагах, которые потом Release Manager собирает в наборы шагов для каждого проекта. Таким образом, можно создать отдельный шаг специфичный для нужного проекта, и он никак не будет влиять на работу шагов других проектов.
Заключение
Получившийся Release Manager оказался очень полезным внутренним продуктом для многих команд разработчиков в компании. Он помог существенно сократить время выпуска очередного релиза, избавил от ненужной рутины, нейтрализовал ошибки ручной сборки и стал основой для дальнейшей кастомизации.
Теперь стало проще соблюдать график выпуска релизов, был организован согласованный конвейер для новых версий, учитывающий потребности всех участников на проекте.
Выбор инструмента остается за вами, но при всем обилии существующих решений создание собственного Release Manager оказалось посильной задачей. Наш алгоритм прошел проверку на работоспособность и может быть взят за основу для создания новых уникальных программных продуктов. Дерзайте!