В современном русском языке существует множество терминов и понятий, которые позаимствованы у иных стран. И знать их все просто нет возможности. Так, в данной статье речь пойдет о таком термине, как релиз: что это такое и как правильно это понятие нужно использовать в различных ситуациях.
Терминология
Изначально надо понять, о чем же именно будет идти речь. Итак, релиз: что это такое и как правильно этот термин расшифровывается? Проще всего для его определения и понимания заглянуть в англо-русский словарь. Именно из английского языка этот термин и позаимствован. В переводе слово release означает «выпуск», «первая публикация», «первичное опубликование».
Если же говорить о нашей стране, то на ее территории слово «релиз» означает краткое сообщение о выходе чего-то нового: программы, игры, песни или иного продукта.
Apple iPhone 15 ULTRA — Дождались! Цена удивила! Обзор фишек, характеристики, дата выхода Айфон 15
Что такое пресс-релиз?
Поняв, как переводится слово «релиз» (что это такое, разобрано выше), хочется пойти немного далее, углубиться в данное понятие. Какая первая ассоциация у многих людей возникает при упоминании данного термина? Слово «пресс-релиз». Что же это такое? Опять же, проще всего сделать перевод с английского языка.
Становится понятно, что это выпуск для прессы. Если же говорить более точно, то пресс-релиз — это сообщение о выходе того или иного продукта в печатных изданиях. А чтобы это сообщение было максимально эффективным, составляться оно должно по особым правилам. Главные требования к пресс-релизу: краткость, максимальная информативность и легкость в восприятии. Он обязательно должен включать следующие пункты:
Ну и, конечно же, пресс-релиз должен быть безупречным с точки зрения стилистики, пунктуации, а также орфографии. Если хочется, чтобы новый бренд стал узнаваемым, обойтись одним только пресс-релизом не удастся. Рассылать их придется регулярно и во множественные издания (при этом важно учитывать аудиторию и особенности газеты или журнала).
О релизе мероприятия
Существует также такое понятие, как релиз мероприятия. Что же это такое? Особого отличия тут нет. Это сообщение о событии. Размещаться оно может не только лишь в прессе (пресс-релиз). Люди о будущем мероприятии могут информироваться иными способами.
К примеру, сообщениями на конференциях, круглых столах, семинарах, форумах. В данном случае цель такая же: рассказать людям о важности и нужности данного мероприятия. Но если в предыдущем случае максимально важен текст, то тут сыграть большую роль может именно тот, кто озвучит данный релиз. Наибольшую аудиторию собирают те действия, которые оглашаются «звездами» шоу-бизнеса или иными узнаваемыми личностями.
НОВОЕ ОБНОВЛЕНИЕ В MELON PLAYGROUND 16.0. ДАТА ВЫХОДА.
Релиз игры
Геймеры частенько ожидают релизы новых игр. Что же это такое? Это сообщение о том, что игра выходит в свет. Она становится общедоступной, ее могут покупать не только в тестовом, но и в полном режиме. После выхода релиза игра уже не меняется, все нюансы и особенности, которые хочется изменить пользователям, учитываются на предыдущих этапах.
Музыкальные релизы
В шоу-бизнесе также существуют музыкальные релизы. Однако для удобства там их разделяют на многие категории:
- Альбом. Около 10 песен одного исполнителя.
- Сингл — одиночная композиция, которая обязана заинтересовать слушателя.
- Саундтрек — музыкальное оформление фильма, передачи.
- Промо. Выходит перед основным релизом, небольшим тиражом для изучения спроса.
- Демо — это незавершенный альбом. В основном выпускается новыми исполнителями для того, чтобы привлечь инвесторов и продюсеров для выпуска полного альбома. Желание заявить о себе.
Существуют еще и иные музыкальные релизы, представлены наиболее узнаваемые обычным человеком.
Пост-релиз
Итак, с вопросом: «Релиз — что это такое?» разобрались. Но пару слов еще хочется сказать и о том, что существует понятие пост-релиза. Так, это сообщение, которое информирует о том, что событие уже состоялось. Формируется так же, как и пресс-релиз. Однако обязательно должно дополняться фотографиями.
Источник: businessman.ru
Home
Управление релизами охватывает все этапы продукта — от разработки и тестирования до продакшена. Это самая ответственная роль, которую может взять на себя IT-специалист. Вместе с коллегами из направления QA SimbirSoft рассказали, на что стоит обратить внимание IT-специалисту, стартующему в роли релиз-менеджера или решившему проанализировать процесс релизов на проекте.
Компетенции релиз-менеджера можно разделить на две части с точки зрения инструментов: техническую и работу с документами.
Это сборка релизной ветки, деплой, настройка, обновление серверов и базы данных.
Более того, подходы к релизам очень часто зависят от архитектуры приложения, размера проектов, а также выбранных GitFlow. Рассмотрим различные технические аспекты, которые напрямую влияют на стратегию релизов.
Монолит VS микросервисы. Одна из специфик монолита заключается в том, что на большом продолжительном проекте в определенный момент команды становятся более изолированы друг от друга, что может привести к появлению багов. Одни специалисты что-то поправили, а у других что-то «отвалилось» (различные версии гайдов на фронте, например, приводят к падению виджетов).
Разделение на микросервисы отчасти решает проблему. Но в этот переходный период нужно максимально осторожно катить релизы, в которых фичи затрагивают не только свой сервис, а монолит в целом. Любые правки в коде могут отразиться на другом разделе, в котором не было изменений. Поэтому до момента полной смены архитектуры на подобные правки стоит обращать особое внимание при тестировании релиза.
CI/CD. На крупных сложных проектах есть простая закономерность: много параллельных сервисов вносят много изменений в develop. Чтобы релизы не были слишком «жирными», лучше увеличить их частоту. Например, ежедневные выкладки в данной ситуации – хорошая практика. Да пребудет с вами CI/CD.
GitFlow. Немного интересных фактов о модели ветвления Git.
Бывает, статусы задач не дают мерджить ветку там, где должны, а где должны НЕ давать мерджить – позволяют.
Ситуация первая: разработчик забыл поменять статус задачи в таск-трекере и смерджил ее в ветку develop после тестирования – такого быть не должно. Все задачи в develop имеют статус «resolved+».
Ситуация вторая: в релизной ветке оказалась задача в некорректном статусе (см. первую ситуацию). Она не даст смерджить релиз в master – срабатывает «защита от дурака», чтобы в master не попадали не протестированные задачи или задачи со статусами «in review» и т.п.
Кроме того, иногда встречаются проекты, в которых GitFlow можно назвать странным. Например, когда релизная ветка создается не от develop, а от master, и в нее переходят изменения из develop. Получается, код сначала дестабилизируется, а потом стабилизируется. Вопрос корректности такой работы остается открытым.
Резюмируя описанное выше, релиз-менеджеру очень важно знать, понимать и соблюдать GitFlow, поскольку это позволит избежать появления «снежных комов» из хотфиксов, багфиксов и релизов. Элементарно: если во время тестирования релиза появляется срочный хотфикс, то при его мердже в master в ветке происходят изменения, которых нет в релизной ветке, и при выкатывании релиза в тот же master возникнет конфликт ревизий. Поэтому важно держать код в актуальном состоянии и не забывать подливать изменения из хотфикса не только в develop, но и в ветку релиза.
Документация и планирование
Регламент релиза. Прежде всего это подробное описание того, как должен происходить деплой на сервер заказчика, в какое время релизиться, что необходимо проверить после релиза, какие пакеты нужно добавлять вручную и любые другие технические нюансы. Регламент очень важно держать в актуальном состоянии и уведомлять об изменениях всех заинтересованных лиц.
Хорошо, если после каждого релиза вы будете общаться с DevOps-инженером или разработчиком, чтобы быть в курсе всех деталей и изменений. Стоит помнить, что актуальный регламент релиза должен быть настоящим спасением для снижения bus factor риска. Не забываем добавить туда и пострелизные мероприятия — описание правил по проведению тестирования на продакшене, действия при откатах, правила работы с хот-фиксами.
Примечание к релизу. Подробные Release Notes (примечания к релизу) помогут быстро ориентироваться в разных версиях продукта и понимать, что мы предоставляем пользователям. А грамотная версионность позволит оценить объем выходящего обновления. Ориентироваться в версиях очень важно в случае, если пользователи долго не обновляются, или при срочных откатах на предыдущую версию. Правильная версионность с Release Notes — это отличный инструмент в расследовании о том, с какой версии просочился баг на продакшен.
Планирование выкладок и расписание. Если сегодня релиз, но появилась еще пара хотфиксов, то стоит обратить особое внимание на их приоритет. Критичные и блокирующие задачи выкатываются в первую очередь, но лучше после выкладки релиза. Чтобы успеть докатить до прода все необходимые изменения, следует планировать порядок деплоя, но это уже другая история, потому что на каждом проекте он свой.
Нет ничего лучше расписания! Во-первых, команды знают, когда у них релиз, и могут планировать выкладку фич. Во-вторых, легче удается планировать реализацию больших задач, которые затрагивают большую часть функционала и взаимодействуют с другими командами. Все очень просто.
Один день из жизни релиз-менеджера
Релиз можно сравнить с локомотивом, который несется несмотря ни на что. Для его управления требуется сноровка и множество технических и управленческих навыков. Однако он также разделен на этапы, в которых участвует вся команда. Чтобы еще глубже понять роль релиз-менеджера, рассмотрим весь жизненный цикл релиза.
1. Собираем список задач, которые должны попасть в релиз. Здесь может быть несколько подходов:
- Заводим задачу релиза в таск-трекере, смотрим в нем задачи, у которых есть атрибут «номер релиза: » и добавляем их списком в общую релизную задачу.
- Заводим задачу в таск-трекере, а оунеры продуктовых команд оставляют комментарии с задачами, которые должны попасть в релиз. Также в комментариях оставляют всю необходимую дополнительную информацию, например: нужно выполнить определенные действия в админке, добавить конфигурации, обновить шаблоны и т.д.
2. Создаем релизную ветку и вливаем все задачи релиза в нее.
3. Собираем релиз-кандидат для проведения регресса.
4. Меняем статус у всех задач, которые попали в релиз-кандидат.
5. Во время регресса следим за блокерами релиза (баги с высокой критичностью, краши). У каждого бага должен быть ответственный, а если его нет, то назначаем, поскольку пока баг не исправлен, релиза не будет.
6. По мере необходимости при исправлении багов регресса собираем новые релиз-кандидаты, обновляем общую задачу, дополнив списком багов, которые заехали в очередном релиз-кандидате, меняем статус у задач.
7. При сборке релиз-кандидатов следим, чтобы заливали только исправления багов, обнаруженные во время регресса. Никакие новые фичи на этом этапе не вливаются, даже если очень хочется. Так как часть функциональности уже проверена, новая фича может повлиять на многое и придется проводить регресс снова, есть риск не уложиться в дедлайн. Тут могут быть исключения — при согласовании и под ответственность команды.
8. Когда последний релиз-кандидат устраивает команду QA и нет багов, которые блокируют релиз, то собирается релизная сборка (такая же, как последний релиз-кандидат).
9. Прописываем релизноты, загружаем сборку в магазин приложений (для мобилок). Для мобилок могут быть тонкости, например, плавная раскатка версии на пользователей.
10. Сообщаем QA, которые имеют доступ «к бою», чтобы они скачали сборку из магазина приложений (мобилки), либо зашли на «боевой» стенд и провели необходимые проверки.
11. Закрываем все задачи, которые заехали в новой версии.
12. Ветку релиза вливаем в мастер, мастер вливает в develop. В мастере добавляем тег с номером версии.
13. В течение нескольких дней после релиза следим за крашами. Дальше по согласованию с тимлидом решаем, нужен ли хот-фикс.
Важно
Весь процесс необходимо задокументировать, подробно описать все тонкости. Команда на проекте должна ознакомиться с плановым графиком релизов и согласно нему готовить задачи.
Релиз-менеджер на каждом этапе следует следить за сроками, которые не должны быть нарушены. В случаях задержки сроков он проводит анализ и выявляет причины отсрочки, что позволяет в следующем спринте избежать подобного на каждом этапе.
Хороший релиз-менджер всегда думает о пользователях: как воспримут новый релиз, как поймут, что он содержит новые фичи, какие данные увидит пользователь при открытии новой страницы, не попадут ли на сервер тестовые данные. Все это должно быть проверено с привлечением QA-команды. Ведь кто еще, если не мы? 🙂
Вывод
Роль релиз-менеджера требует достаточно сильной технической подготовленности с точки зрения знаний инструментов, но также многое зависит и от менеджерской закалки. Если в команде нет выделенной роли, то ответственность за релиз распределяется между членами команды. Но главным контролером часто становится QA-специалист — именно так происходит в SimbirSoft. Мы считаем, что лучше формализовать данную роль, обеспечить выделенное пространство для хранения релизной документации и отладить процессы релизов, тогда успешные деплои в срок, а также положительные отзывы клиентов о новых версиях не заставят себя ждать.
Спасибо за внимание! Полезные материалы для QA-специалистов мы также публикуем в наших соцсетях – ВК и Telegram.
Источник: www.software-testing.ru
Почему планирование релизов продукта – один из самых важных этапов проекта
Планирование релиза – это метод управления продуктом, при котором вы разрабатываете стратегию его поэтапного выпуска.
Миша Ряженка
Founder, Executive Partner
Что такое планирование релиза?
Планирование релиза – это метод управления продуктом, при котором вы разрабатываете стратегию его поэтапного выпуска.
Миша Ряженка
Founder, Executive Partner
Что такое дорожная карта продукта?
Дорожная карта продукта (Roadmap) – это достоверный источник информации, который описывает видение, направление и прогресс работы над продуктом с течением времени.
Миша Ряженка
Founder, Executive Partner
Когда лучше всего начинать планирование релизов?
Планирование релиза обычно происходит после того, как вы составили свое видение и дорожную карту проекта.
Продакт–менеджер
Долгосрочная программа
Обучение с нуля профессии «Продакт–менеджер» в IT на реальных рыночных кейсах. Передадим вам практический коммерческий опыт и подготовим к трудоустройству.
