что такое релиз продукта
Как организовать релиз
Как готовиться к релизу?
Выбрать ответственного человека
Можно дежурить по очереди, либо бросать игральные кости, либо тянуть спички —любой способ хорош. Важна ротация людей и обучение тех, кто не умеет делать релиз. Например, при броске костей можно ввести правила что тот, кто дежурил в прошлый раз, имеет право перебросить, а если дежурил два раза подряд, то автоматически не дежуришь. Дежурство не должно восприниматься как наказание или повинность, и обязательно должны быть люди, которые могут подстраховать.
Настроить календарь
Настроить дату в корпоративном календаре и убедится что все стейкхолдеры в курсе.
Сделать таблицу в вики
Укажите таблице версию, дату и человека, ответственного за релиз. Это больше нужно для ведения исторических данных. Можно и нужно тут же отметить, был ли релиз успешный и что именно вошло в релиз.
Release notes
Это то самое “что именно вошло в релиз”. В первую очередь, этими данными нужно поделится с аналитиками: любые изменения в KPI они могут сравнивать с тем, что вошло в релиз. На основании этих данных они могут делать выводы, какой функционал нужен пользователям, какие идеи хорошие, а какие нет, и что войдет в следующею итерацию.
Внутренний анонс
Другим отделам важно знать когда произошел релиз, чтобы, например, сделать посты в соц. сетях о новой версии продукта (создать инфоповод), следить за KPI (возможен рост или падение метрик) и т.д.
Во время релиза
Создать релизный бранч
Код, который подлежит выпуску не должен меняться, за исключением исправления критических багов. И в идеальном случае любой фикс должен пройти пул-реквест. Так же все тесты должны быть зеленые.
Отправить уведомление
Нужно уведомить всех по почте или в мессенджере о том, что создан релизный бранч и идет подготовка к релизу.
Сделать тэг
Обязательно сделать тэг, когда релиз финализирован, и затянуть фиксы в девелоп-ветку.
Сделать сам релиз
В идеальном варианте у вас должны быть механизмы, которые контролируют релиз: например, сделать релиз только на 10% пользователей или только на не платящих. Это необходимо для того. чтобы уменьшить урон от ошибок, которые возникли в процессе разработки и не были найдены во время тестирования.
Релиз одной кнопкой
Мифический. Безусловно, чем меньше человеческого фактора участвует в релизе, тем лучше. Но это нормально, если не все получается автоматизировать.
Если все пошло не так, как планировалось
Конечно же в случае какой-либо ошибки нельзя друг друга обвинять, а нужно решить проблему вместе и придумать план по предотвращению подобных инцидентов в будущем.
После релиза
Мониторить
Не забывайте мониторить ошибки, нагрузку на сервера. Также стоит обратить внимание на KPI: если вы сделали релиз и у вас упало DAU, то, возможно, что-то работает не так хорошо, как должно было, либо сломаны сами средства мониторинга. Любую подозрительную активность стоит проверить.
Сообщить об успехах и неудачах
Намного лучше если о проблеме узнают от разработчиков, а не от пользователей. И конечно же, если вы решили какие-то проблемы, то этим можно смело похвалиться.
Провести ретроспективу
Это, конечно же, частично зависит от методологии разработки, но если что-то в процессе релиза пошло не так — это стоит обсудить. Если что-то было хорошо, то это также стоит обсудить. В идеале на доске на каждый пункт неудачи должен быть пункт успеха либо благодарность коллеге. Это поможет не скатить ретроспективу в нытье и негатив.
Заказать пиццу и отпраздновать
Во время таких посиделок просто коллеги становятся друзьями и боевыми товарищами. А это значит, что в следующем бою друзья не подведут.
Начать подготовку к следующему релизу
Мне очень нравится идея Release train, когда каждый релиз проходит регулярно в четко обозначенные даты. Благодаря этому механизм релиза отлаживается командой. Как я писал выше, не обязательно делать релиз на 100% пользователей: можно выкатить на небольшую группу людей.
Software versioning
Методология изменения версий продукта программного обеспечения
Software versioning — это процесс создания уникальных имен или номеров для различных версий продуктов программного обеспечения.
При имеющейся категории номера версии (главная, второстепенная), номера обычно выставляются в возрастающем порядке и соответствуют новым разработкам в программном обеспечении. На начальном уровне отслеживанием постепенно появляющихся версий электронной информации занимается система управления версиями, позволяющая хранить несколько версий одного и того же документа, при необходимости, возвращаться к более ранним версиям, определяя, кто и когда сделал то или иное изменение и многое другое. Вместе с тем для отслеживания изменений программного обеспечения было создано большое количество схем присвоения номеров версиям.
Каждой стадии разработки программного обеспечения соответствует уникальный идентификатор, который состоит из последовательности номеров или букв. В некоторых схемах последовательные идентификаторы используются для определения значимости перемен между стадиями разработки: эти перемены классифицируются по уровням значимости. Решение о том какую последовательность изменить между стадиями разработки основано на значимости перемен на последней стадии разработки, например в схеме, с версией, состоящей из последовательности 4 чисел, первое число может быть прибавлено только тогда когда код полностью переписан, в то время как четвертое число изменяется при незначительных переменах в интерфейсе или документации.
В более поздних релизах, главное число (major) увеличивается, когда происходят значительные переходы в функциональности, второстепенное число (minor) прибавляется только тогда, когда были добавлены незначительные функции или внесены исправления. Номер версии изменяется, если исправлены все мелкие неполадки. Для типичного программного продукта используются следующие номера: 0.9 (для бета-версии), 0.9.1, 0.9.2, 0.9.3, 1.0, 1.0.1, 1.0.2, 1.1, 1.1.1, 2.0, 2.0.1, 2.0.2, 2.1, 2.1.1, 2.1.2, 2.2, и т.д. Разработчики порой перескакивают от версии 5.0 сразу к 5.5, для того чтобы обозначить добавление нескольких значимых функций в программе, однако их не достаточно, чтобы изменить главный номер версии, тем не менее такие скачки все же неуместны.
Другой подход использования главных и второстепенных номеров версий заключается в добавлении буквенно-цифровой последовательности, определяя тем самым стадию разработки релиза: «альфа», «бета», «релиз кандидат». Серия версий с использованием этого подхода может выглядеть следующим образом: если к версиям 0.5, 0.6, 0.7, 0.8, 0.9 добавляются новые функции их можно назвать — 1.0b1, 1.0b2, еще плюс новые функции — 1.0b3, затем версия становится 1.0rc1. Если версия 1.0rc1 достаточно стабильна, то она становится 1.0, однако если в 1.0rc1 обнаруживаются ошибки, которые необходимо исправить она будет иметь номер 1.0rc2 и т.д. Важной характеристикой этого подхода является соблюдение идентичности стадий разработки версий. Нельзя вносить никаких изменений между последней бета-версией и первым релиз кандидатом или последним релиз кандидатом и готовым продуктом. Если вы это сделали, необходимо выпустить другую версию на более низкой стадии разработки.
Известные примеры буквенно-цифровых версий — Macromedia Flash MX, Adobe Photoshop CS2.
Иногда присутствие человеческого фактора в создании номеров версий приводит к ошибкам в изменении версий. Например, разработчики могут изменить последовательность между версиями, даже если одна строчка кода не была переписана, лишь для того чтобы создать ложное впечатление, что были внесены значительные изменения.
Обозначение стадии разработки
Для присвоения альфа или бета статуса релизам, которые еще не достаточно стабильны для практического применения, существуют схемы, где в первой последовательности используется ноль. Он ставится третьим числом в тех случаях, когда планируется еще тестировать версию или версия годна только для внутреннего применения.
Разделение последовательностей
При публикации последовательности могут быть разделены знаками препинания. Выбор знаков препинания и их использования зависит от схемы.
Номера последовательностей
Приращение последовательности
Существует два разных способа приращения последовательности номеров в версии. Большинство продуктов свободного программного обеспечения используют непрекращаемый поток последовательных номеров: 1.7.0, 1.8.0, 1.8.1, 1.9.0, 1.10.0, 1.11.0, 1.11.1, 1.11.2, и т.д. Примером такого продукта может служить MediaWiki. В других программах используются десятичные номера: 1.7, 1.8, 1.81, 1.82, 1.9, и т.д. В таких программах после версии 1.8 будет идти версия 1.81, текущие релизы будут обозначаться 1.81a, 1.81b, и т.д.
Использование дат в версиях
Разработчики проекта Wine использовали даты при нумерации версий, они указывали год, месяц и день релиза: «Wine 20040505». Сейчас Wine использует «стандартную» нумерацию релизов, последняя версия 2010 года имеет номер 1.2. Компания Ubuntu Linux использует похожую схему нумерации, например релиз апреля 2010 года пронумерован как Ubuntu 10.04. Номера сборок Microsoft Office тоже на самом деле закодированные даты.
Здесь следует отметить, что при использовании дат в нумерации версий необходимо использовать схему ISO, то есть сначала указывается год, затем месяц, а потом день (YYYY-MM-DD), причем дефис можно опускать.
Существуют также примеры нумерации версии годом выпуска (Adobe Illustrator 88, WordPerfect Office 2003). Хотя такой ход чаще всего используется в маркетинговых целях, и настоящий номер версии все равно существует. Например, версия Microsoft Windows 2000 Server на самом деле имеет номер Windows NT 5.0.
Схема нумерации версий TeX
Система TeX использует уникальную схему нумерации версий. После появления версии номер 3, ко всем последующим обновленным версиям после точки добавляли цифру, соответствующую последовательности числа Π это одна из форм унарной системы счисления – номер версии соответствует номеру цифры в числе Π. Номер последней версии 3.1415926. Такой метод отражает стабильность системы TeX. Разработчик TeX Дональд Кнут сказал, что последняя версия выйдет после его смерти и ее номер будет полное число Π, в которой все оставшиеся недочеты станут постоянными функциями. Подобной схемы придерживается METAFONT, нумеруя версии числами из математической константы e.
Схема Apple
,Apple использует формализованную структуру нумерации версий основанную на структуре NumVersion, она состоит из номера главной версии (1-2 числа), номера второстепенной версии (1 число), номера исправленной версии («bug» version) (1 число), индикатора стадии разработки (преальфа, альфа, бета и т.д.) и номера пререлиза (0-255). При написании этих номеров версий в строке, существовало условное соглашение опускать часть номера, обозначающую нулевую или последнюю стадию разработки. На пример: 1.0.2b12, 1.0.2 (вместо 1.0.2f0), и 1.1 (вместо 1.1.0f0).
Другие схемы
Производители программного обеспечения используют различные схемы для обозначения релиза их софта. Например, операционная система Microsoft Windows появилась на рынке со стандартной числовой схемой обозначения версий (от Windows 1.0 до Windows 3.11). Позднее разработчики Microsoft начали разделять названия версий в маркетинговых целях, то есть, сначала используя год релиза (Windows 95 (4.0), Windows 98 (4.10), Windows 2000 (5.0)), потом буквенно-цифровые коды (Windows Me (4.90), Windows XP (5.1)), после чего названия брендов (Windows Vista (6.0)). Судя по последнему релизу Windows 7, Microsoft снова вернулся к стандартной числовой схеме, хотя официальное название версии Windows 7 это 6.1.
В проекте Debian для релизов операционной системы используется «major/minor» схема, а для названий программных продуктов при разработке используются имена из мультфильма «История Игрушек».
Скрытые номера версий
Продукт программного обеспечения может иметь так называемый «скрытый» номер версии, который не указан в основном названии продукта (обычно в составлении скрытого номера соблюдаются все правила нумерации версий). Например, версия Java SE 5.0 имеет внутренний номер 1.5.0, а версии Windows начиная от NT 4, продолжают внутреннюю стандартную нумерацию версий: Windows 2000 это NT 5.0, XP это Windows NT 5.1, 2003 это NT 5.2, Vista это NT 6.0 и 7 это NT 6.1.
Предварительные версии продуктов программного обеспечения
Вместе с различными схемами обозначения версий, перечисленными выше, система, обозначающая предварительные версии используется в большинстве случаев как программа, прокладывающая себе путь через все стадии разработки программного обеспечения. Программы, находящиеся на ранних стадиях разработки называются «альфа» (первая буква греческого алфавита). Более зрелые программы, но еще не готовые к релизу называются «бета» (вторая буква греческого алфавита). В основном продукты программного обеспечения «альфа» тестируются только разработчиками, в то время как продуты «бета» распространяются на публичное тестирование. Этим двум версиям продукта обычно присваивается номер меньше 1, например 0.9, так как 1.0. это уже для публичного релиза. Однако если создается предварительная версия к уже существующему продукту, то она может быть обозначена буквой «а» (значит альфа) добавленной к номеру версии готового продукта, например версия 2.5 – предварительная версия 2.5.а или 2.5а. Продукты готовые к релизу могут быть обозначены тегом «rc-#», что означает релиз кандидат (release candidate). Когда версия уже выпущена, тег убирается.
Нечетные числа в обозначении версий для разработки релиза
Между сериями 1.0 и 2.6.x, Linux kernel использовал нечетную нумерацию версий, что бы обозначить релизы в разработке, а для стабильных релизов четную нумерацию. Например Linux 2.3 была серия разработок второго главного дизайна Linux kernel, а Linux 2.4 была серия стабильных релизов, в которую перерос Linux 2.3. В номере релиза Linux kernel сначала писался номер второстепенной версии, а затем номер релиза в возрастающем порядке. Например Linux 2.4.0 → Linux 2.4.22. После релиза 2.6 kernel в 2004 году, Linux больше не использует эту систему, теперь цикл релиза намного короче. Сейчас они просто увеличивают третье число, используя четвертое при необходимости.
Apple и нечетные числа
У компании Apple были свои особенности на счет нечетных чисел, особенно во время системы MacOS. Даже тогда когда выпускались второстепенные (minor) релизы номер версии редко был больше чем 1, а если номер нужно было увеличить они перескакивали сразу на 5, предлагая при этом небольшое изменение величины между главным и второстепенным релизом (например, 8.5 значит «восемь с половиной», а 8.6 значит «восемь с половиной точка один»). Завершенная последовательность версий выглядит так: 1.0, 1.1, 2.0, 2.1, 3.0, 3.2 (3.1 пропущена), 4.0, 4.1, 5.0, 5.1, 6.0, 7.0, 7.1, 7.5, 7.6, 8.0, 8.1, 8.5, 8.6, 9.0, 9.1, 9.2.
Версия 1.0 как ключевой этап разработки
Разработчики проприетарного программного обеспечения всегда называют первый релиз программы версия 1, а затем увеличивают номер главной версии после каждого переписывания кода. Это значит, что программа может достичь версии 3 всего за несколько месяцев разработки, при этом она еще возможно не станет стабильной и надежной.
В отличие от компаний, сообщество свободного программного обеспечения используют версию 1.0 как ключевой этап разработки, обозначая тем самым, что продукт завершен, в нем есть все необходимые функции, и он достаточно надежен для публичного использования.
Согласно этой схеме, номер версии медленно приближается к 1.0 пока устраняются все недочеты в подготовке к релизу. Разработчики MAME, например, не стремятся выпускать версию 1.0 программы эмулятора, аргументируя это тем, что она никогда не будет до конца завершена, потому что аркадные игры будут появляться всегда. За версией 0.99 просто следует версия 0.100. Подобный пример Xfire, после релиза 1.99 идет 1.100. Так за 6 лет существования eMule все еще не достигли версии 0.50.
История программ
Winamp выпустил совершенно иную конфигурацию третьей версии программы, в которой отсутствовала обратная совместимость с плагинами и другими ресурсами предыдущей версии. Однако, эта версия стала полностью совместимой с версиями 2 и 3, но нумеровалась пятой, то есть 4 была пропущена… То же самое произошло с UnixWare 7, что было соединением UnixWare 2 и Open Server 5.
Как не отставать от конкурентов
В индустрии проприетарного программного обеспечения существует общая привычка перескакивать в нумерации главных и второстепенных версий в маркетинговых целях.
Это можно увидеть на примере нескольких продуктов Microsoft и America Online, а также в системе нумерации версий Sun Solaris, Java Virtual Machine, в версиях SCO Unix и Corel Word Perfect. Программные продукты filePro DB/RAD имели нумерацию от 2.0 к 3.0 к 4.0 к 4.1 к 4.5 к 4.8 к 5.0, и они уже готовят релиз 5.6, не имея при это ни одного промежуточного. Небольшую разницу можно заметить между версиями программного обеспечения AOL’s PC client, хотя они нумеруют только главные релизы — 5.0, 6.0, 7.0, и т.д. Таким же образом Microsoft Access перескочили от версии 2.0 к версии 7.0, чтобы догнать нумерацию версий Microsoft Word.
У корпорации Microsoft тоже была цель догнать нумерацию версий браузера Netscape, пропустив версию 5 и выпустив сразу шестую версию Internet Explorer.
Суеверия
У релиза 2007 программы Microsoft Office был внутренний номер версии 12. Релиз Office 2010 внутренне нумеровался уже 14, из-за плохой репутации чертовой дюжины.
Версия 13 WordPerfect Office программы Corel обозначена в продаже как «X3» (римская цифра 10 и «3»). Процедура повторилась в следующей версии X4.
Как преодолеть маркетинговые трудности
В середине 1990х быстро развивающиеся на китайском рынке CMMS и Maximo, перескакивали от версии Maximo Series 3 сразу к Series 5, пропуская Series 4, так как неправильное произношение номера 4 на китайском языке могло означать «смерть» или «неудача». Хотя это, однако, не остановило Maximo Series 5 при выпуске релиза 4.0. Следует отметить, что на этом нумерация Series остановилась, но возобновилась вполне успешно, начиная с релиза 1.0.
Значимость нумерации версий в разработке программного обеспечения
Номера версий используются в практических условиях потребителем или клиентом для того, чтобы можно было сравнить имеющуюся у них копию продукта программного обеспечения и новую версию, выпущенную разработчиком. Команда программистов и компании используют нумерацию версий для сравнения отдельных частей и секторов программного кода одних версий с другими, обычно сотрудничая с Системой контроля версий. Не существует абсолютной и определенной схемы нумерации версий продуктов программного обеспечения, поэтому очень часто нумерация зависит от личного выбора программистов.
Перевод осуществлен сотрудницей компании «Chyrius» Натальей Володиной.
Релиз: что это такое и как правильно использовать данный термин
В современном русском языке существует множество терминов и понятий, которые позаимствованы у иных стран. И знать их все просто нет возможности. Так, в данной статье речь пойдет о таком термине, как релиз: что это такое и как правильно это понятие нужно использовать в различных ситуациях.
Терминология
Изначально надо понять, о чем же именно будет идти речь. Итак, релиз: что это такое и как правильно этот термин расшифровывается? Проще всего для его определения и понимания заглянуть в англо-русский словарь. Именно из английского языка этот термин и позаимствован. В переводе слово release означает «выпуск», «первая публикация», «первичное опубликование». Если же говорить о нашей стране, то на ее территории слово «релиз» означает краткое сообщение о выходе чего-то нового: программы, игры, песни или иного продукта.
Что такое пресс-релиз?
Поняв, как переводится слово «релиз» (что это такое, разобрано выше), хочется пойти немного далее, углубиться в данное понятие. Какая первая ассоциация у многих людей возникает при упоминании данного термина? Слово «пресс-релиз». Что же это такое? Опять же, проще всего сделать перевод с английского языка. Становится понятно, что это выпуск для прессы. Если же говорить более точно, то пресс-релиз — это сообщение о выходе того или иного продукта в печатных изданиях. А чтобы это сообщение было максимально эффективным, составляться оно должно по особым правилам. Главные требования к пресс-релизу: краткость, максимальная информативность и легкость в восприятии. Он обязательно должен включать следующие пункты:
Ну и, конечно же, пресс-релиз должен быть безупречным с точки зрения стилистики, пунктуации, а также орфографии. Если хочется, чтобы новый бренд стал узнаваемым, обойтись одним только пресс-релизом не удастся. Рассылать их придется регулярно и во множественные издания (при этом важно учитывать аудиторию и особенности газеты или журнала).
О релизе мероприятия
Существует также такое понятие, как релиз мероприятия. Что же это такое? Особого отличия тут нет. Это сообщение о событии. Размещаться оно может не только лишь в прессе (пресс-релиз). Люди о будущем мероприятии могут информироваться иными способами. К примеру, сообщениями на конференциях, круглых столах, семинарах, форумах. В данном случае цель такая же: рассказать людям о важности и нужности данного мероприятия. Но если в предыдущем случае максимально важен текст, то тут сыграть большую роль может именно тот, кто озвучит данный релиз. Наибольшую аудиторию собирают те действия, которые оглашаются «звездами» шоу-бизнеса или иными узнаваемыми личностями.
Релиз игры
Геймеры частенько ожидают релизы новых игр. Что же это такое? Это сообщение о том, что игра выходит в свет. Она становится общедоступной, ее могут покупать не только в тестовом, но и в полном режиме. После выхода релиза игра уже не меняется, все нюансы и особенности, которые хочется изменить пользователям, учитываются на предыдущих этапах.
Музыкальные релизы
В шоу-бизнесе также существуют музыкальные релизы. Однако для удобства там их разделяют на многие категории:
Существуют еще и иные музыкальные релизы, представлены наиболее узнаваемые обычным человеком.
Пост-релиз
Итак, с вопросом: «Релиз — что это такое?» разобрались. Но пару слов еще хочется сказать и о том, что существует понятие пост-релиза. Так, это сообщение, которое информирует о том, что событие уже состоялось. Формируется так же, как и пресс-релиз. Однако обязательно должно дополняться фотографиями.
Корпоративный 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 оказалось посильной задачей. Наш алгоритм прошел проверку на работоспособность и может быть взят за основу для создания новых уникальных программных продуктов. Дерзайте!