что такое релизы в jira
Как выпустить релиз в проекте
Чтобы отследить прогресс по задачам, необходимо регулярно (примерно раз в 2 недели) выпускать релизы, в которые будут входить все выполненные на неделе задачи.
После того как релиз создан, задачи скрываются из столбца Выполнено на канбан доске.
Чтобы выпустить релиз, нажмите ссылку Релиз над канбан панелью.
В открывшемся окне введите имя релиза:
Имя релиза (продукта) строится из кода продукта и даты выпуска в формате ДДММГГ. Например, для проекта RTFM релиз, выпущенный 26 сентября, будет называться: RTFM-260916.
После ввода имени, нажмите кнопку Выпуск.
Список всех релизов можно найти в разделе проекта, нажав в боковой панели иконку с изображением корабля:
В этом разделе вы можете сразу запланировать выпуск следующего релиза. Для этого введите его название в поле над таблицей и нажмите Добавить.
Как найти и проверить задачи, в которых вы автор
Чтобы найти решенные задачи, которые нуждаются в вашем утверждении откройте системный рабочий стол и на нем таблицу Проверить Выполненные Задачи.
Чтобы открыть список всех задач, нажмите на их количество внизу данной таблицы. Чтобы перейти к задаче, нажмите на её название.
Все задачи, которые нуждаются в проверке имеют статус Выполнено. Чтобы утвердить задачу, нажмите кнопку Проверено. Если она нуждается в доработках, опишите их в комментарии и верните задачу в работу на исполнителя с помощью кнопку На доработку.
Изучение версий с программным обеспечением JIRA
Изучите версии с помощью программного обеспечения Jira
Узнайте, как использовать версии в Jira Software
Руководство по использованию версий в Jira Software
Учебник по версиям в Jira
В этом уроке мы расскажем, как работать с версиями в Jira Software.
Время:
10 минут чтения. Завершить в течение 2 недель или более.
Аудитория: Вы знакомы с тем, как Scrum и / или Kanban работают в Jira Software
У вас есть разрешение на управление проектами для всех проектов на вашей доске Scrum или Kanban.
См. Управление разрешениями проекта для получения дополнительной информации.
Необходимое условие (Предпосылки):
В программном обеспечении Jira версии представляют моменты времени для проекта. Они помогают вам организовать вашу работу, давая вам вехи, к которым нужно стремиться. Вы можете назначить задачи в своем проекте определенной версии и организовать свои спринты вокруг завершения работы в этой версии.
Шаг 1. Создайте версию в Jira Software
Имена версий обычно бывают числовыми, например, 1.0 или 2.1.1. Вы также можете рассмотреть возможность использования внутреннего кодового имени.
СКОЛЬКО ВЕРСИЙ Я ДОЛЖЕН СОЗДАТЬ?
Вы можете создать их столько, сколько считаете нужным. Например, вы можете создать несколько версий, чтобы планировать заранее. Или вы можете просто иметь одну или две версии на данный момент.
После того, как вы создадите версию, поля «Затронутая версия» (Affects version) и «Исправленная версия» (Fix version) станут доступными для ваших проблем.
Шаг 2. Добавьте задачи в версию
Если ваш проект имеет список основных требований (backlog):
Если ваш проект не имеет списка основных требований (backlog), откройте задачу, которую вы хотите добавить в версию.
Найдите поле «Исправленная версия» (ии) (Fix version / s) и введите версию, к которой хотите добавить задачу.
Шаг 3: Отслеживание прогресса версии
Программное обеспечение Jira Software предоставляет вам множество инструментов, которые вы можете использовать для проверки хода версии. Мы обсудим некоторые из них здесь.
Центр выпуска релиза
Центр выпуска релизов предоставляет вам место для управления всеми вашими релизами. Он также дает вам информацию о состоянии ваших выпусков релизов и разбивку по количеству задач в каждой версии.
Чтобы перейти к центру выпуска релиза:
Перейдите к вашему проекту.
В меню проекта выберите Релизы (Releases).
ХОТИТЕ УЗНАТЬ БОЛЬШЕ ИНФОРМАЦИИ ЧТОБЫ ПОМОЧЬ ВАМ КОНТРОЛИРОВАТЬ ВЫПУСКИ РЕЛИЗОВ?
Если вы интегрируете программным обеспечением Jira Software с вашим репозиторием Bitbucket, вы также увидите здесь информацию о разработке, касающуюся ваших коммитов, веток и запросов на получение.
Выпуск релиза диаграммы сгорания (только Scrum)
Диаграмма сгорания выпуска релиза показывает, сколько работы было выполнено, а так же общую оставшуюся работу. Диаграммы сгорания используются для прогнозирования вероятности того, что ваша команда выполнит (завершит) свою работу в заданное время. Они также отлично подходят для того, чтобы держать команду осведомленной о масштабе задержек, которые возникают.
Чтобы просмотреть диаграмму сгорания выпуска релиза:
Для получения более подробной информации, ознакомьтесь с нашей документацией по диаграмме сгорания выпуска релиза.
Шаг 4: Завершите версию
Чтобы развернуть выпуск релиза, вы обычно выпускаете версию в программном обеспечении Jira Software, собираете выпуск релиза и затем развертываете его в требуемой среде.
Для завершения версии
На досках Kanban вы также можете выпустить релизы всех задач в колонке «Готово» (Done) в виде новой версии непосредственно с самой доски.
Что узнать больше?
Более подробную информацию о работе с версиями в программном обеспечении Jira Software можно найти в документации по нашим версиям.
Есть вопросы? Спросите Сообщество Atlassian.
Узнайте, как использовать версии в Jira Software
Руководство по использованию версий в Jira Software
Просмотр тем
Учебное руководство по версиям Jira
Из этого учебного руководства вы узнаете, как можно работать с версиями в Jira Software.
10 минут на прочтение. Прохождение учебного курса занимает не менее 2 недель.
Вы знакомы с принципами работы с досками Scrum и (или) Kanban в Jira Software
У вас есть права на администрирование всех проектов на вашей доске Scrum или Kanban. Дополнительную информацию см. на странице «Управление правами на уровне проекта».
Вы создали проект Scrum или Kanban в Jira Software
Вы добавили в проект задачи
Версии в Jira Software отражают состояние проекта на определенный момент времени. Они помогают организовать работу посредством создания контрольных точек, которых необходимо достичь. Вы можете связать задачи проекта с конкретной версией и организовать спринты для выполнения работы в рамках этой версии.
Шаг 1. Создание версии в Jira Software
В меню проекта нажмите Releases (Релизы).
Выберите текстовое поле Version name (Имя версии), введите имя и нажмите Add (Добавить).
Имена версий обычно состоят из цифр, например 1.0 или 2.1.1. Можно также использовать внутреннее кодовое имя.
Вы можете создать ровно столько версий, сколько необходимо. Создание нескольких версий поможет спланировать работу заранее, однако для начала можно ограничиться лишь одной или двумя.
После создания версии для ваших задач станут доступны поля Affects version (Затрагиваемая версия) и Fix version (Версия фикса).
Шаг 2. Добавление задач к версии
Если у проекта есть бэклог
Перейдите в бэклог проекта.
Откройте панель Versions (Версии) слева.
Перетащите задачу в нужную версию для добавления.
Если у проекта нет бэклога
Откройте задачу, которую нужно добавить в версию.
Найдите поле Fix version/s (Версия исправления) и введите имя версии, в которую нужно добавить задачу.
Затрагиваемая версия — это версия, в которой были обнаружены баг или проблема. Информация о таких версиях может быть полезна при отслеживании проблем, однако они используются в Jira довольно редко.
Версия фикса — это версия для клиентов, в рамках которой планируется выпуск новой возможности или устранение багов. Это поле используется для планирования релизов, отслеживания работы и скорости ее выполнения, а также для составления отчетов. Скорее всего, вы будете пользоваться им чаще остальных в процессе работы.
Шаг 3. Отслеживание работы над версией
Jira Software содержит множество инструментов, с помощью которых вы можете следить за работой над версией. Далее мы поговорим о некоторых из них.
Центр управления релизами
В центре управления релизами вы можете управлять всеми релизами, а также просматривать сведения о состоянии релизов и количестве задач в каждой версии.
Переход в центр управления релизами.
В меню проекта выберите Releases (Релизы).
Быстрые фильтры. Отобразите конкретные версии, исключив все остальные.
Список версий. Перетаскивайте версии, чтобы изменить их порядок.
Состояние. Версии могут находиться в одном из трех состояний: Unreleased (Не выпущена), Released (Выпущена) или Archived (В архиве).
Прогресс. Здесь показано количество задач, связанных с конкретной версией, а также состояние каждой задачи.
При интеграции Jira Software с репозиторием Bitbucket вы также увидите здесь информацию о разработке, связанную с коммитами, ветками и запросами pull.
Burndown-диаграмма релиза (только для Scrum)
На диаграмме Burndown релиза показан объем выполненной и оставшейся работы. С помощью таких диаграмм можно спрогнозировать, выполнит ли команда работу в срок. Они также отлично подходят для того, чтобы сообщить команде о расширении области проекта.
Обратите внимание: прежде чем использовать диаграмму Burndown релиза, необходимо оценить сложность задач. Подробнее см. в нашем руководстве по диаграммам Burndown.
Чтобы просмотреть диаграмму Burndown релиза, выполните следующие действия.
В меню проекта выберите Reports (Отчеты).
Выберите Release burndown (Диаграмма Burndown релиза).
Меню релизов. Выбор релиза, информацию по которому нужно просмотреть.
Добавленная работа. Сегменты темно-синего цвета отображают объем работы, добавленный в каждый спринт релиза. В этом примере объем работы измеряется в очках за пользовательские истории.
Оставшаяся работа. Сегменты светло-синего цвета отображают оставшийся объем работы в релизе.
Выполненная работа. Сегменты зеленого цвета отображают объем работы, выполненной в рамках каждого спринта в релизе.
Ожидаемое время завершения. В отчете показано, сколько спринтов потребуется для завершения работы над релизом с учетом скорости работы команды.
Шаг 4. Завершение работы над версией
Ваша команда усердно потрудилась — настало время выпустить релиз ПО. На этом этапе вы должны быть уверены, что версия готова к релизу. Убедитесь, что все задачи выполнены, код загружен и проверен, выполнено его слияние, сборки успешно протестированы и т. д.
Для развертывания релиза чаще всего необходимо выпустить версию в Jira Software, после чего выполнить сборку релиза и его развертывание в нужной среде.
Завершение работы над версией
Перейдите в проект.
В меню проекта выберите Releases (Релизы).
Кнопка «. »Выберите Actions (
) > Release (Действия > Выпустить) для версии, которую нужно выпустить.
На досках Kanban можно также выпустить все задачи из столбца Done (Выполнено) в качестве новой версии прямо со страницы доски.
Автоматизация позволяет оптимизировать работу с версиями в Jira. Эти и сотни других правил автоматизации можно найти в библиотеке шаблонов Jira Automation. Перейти в библиотеку
Хотите узнать больше?
Подробнее о работе с версиями в Jira Software см. в нашей документации по версиям.
Реализация процедуры «Планирование выпуска релизов по продуктам» инструментами семейства Atlassian
Это мой доклад с Meetup-а Московской Atlassian User Group от 1 марта 2017 года
Контекст и задача
Компания самостоятельно разрабатывает программное обеспечение (Продукты) под нужды своих бизнес-подразделений (Заказчиков). Некоторые из продуктов поставлены заказчикам и компания занимается их доработкой-развитием.
Есть общий перечень задач по каждому из продуктов (Product Backlog). Каждый месяц выходят новые релизы по некоторым продуктам.
Цель – ответить на вопрос по каким продуктам необходимо выпустить релизы и какие клиентские запросы войдут в каждый из релизов.
Результат – план разработки на следующий производственный цикл (Sprint Backlog). Список релизов по продуктам, которые будут выпущены в следующем цикле.
Бизнес-логика
Каждый из продуктов закреплен за Менеджером по продукту (Product Owner). Каждое бизнес-подразделение закреплено за IT-Business Partner-ом (Менеджер по клиенту). Менеджер по клиенту обращается к Менеджеру по продукту с возможным заказом на разработку (User Story). Если Менеджеру по продукту «боль Заказчика» и «запрошенная таблетка» понятны, то он запрашивает у Руководителя команды разработки (Team Lead-а) оценку возможности реализации опции в продукте и приблизительную трудоемкость. По результатам оценки Заказчик либо подтверждает размещение заказа либо отказывается. Так формируется список запросов на доработку продуктов (Product Backlog).
Общая трудоемкость клиентских запросов на доработки превышает количество доступных ресурсов на их исполнение в производственном цикле. Чтобы понять какие запросы необходимо сделать в первую очередь, ежемесячно Менеджер по продукту обращается к Менеджерам по клиентам с просьбой приоритезировать список запросов по своим Заказчикам и указать какие из них они хотят получить в результате выполнения очередного цикла разработки (Sprint-а). Так появляется первая версия плана разработки на очередной цикл, состоящий из запросов, отмеченных Менеджерами по клиентам.
Каждый из продуктов также закреплен за одной из команд разработки. Менеджер по продукту запрашивает у Руководителя команды разработки доступные часы разработчиков на будущий цикл (Sprint Capacity).
Менеджер по продукту сравнивает трудоемкость первичного плана с доступной мощностью команд. Если пожелания Менеджеров по клиентам превышают доступные ресурсы, Менеджер по продукту просеивает задачи через сито критериев выгодности для Компании. На выходе вторая версия плана разработки с самыми выгодными для компании запросами с трудоемкостью реализации соответствующей мощности команд на цикл.
Запросы внутри плана группируются по продуктам (релизам) и выставляется очередность их реализации внутри релиза (повторная приоритезация). Это указывает командам какие запросы в какой последовательности реализовывать. Полученный план (Sprint Backlog) доводится до Менеджеров по клиентам и размещается на внутреннем портале.
Техническая реализация семейством продуктов Atlassian
JIRA Sotware
Выступает платформой для всего ИТ-решения. Обеспечивает реализацию бизнес-функции по ведению учёта запросов на разработку и доработку продуктов.
Используются стандартные возможности JIRA по добавлению пользовательских полей (custom fields) для хранения и последующей обработки информации по запросам.
Для планирования понадобится добавить следующие поля:
JExcel
Как следует из названия он представляет собой подобие Excel-я. Это плагин JIRA, который даёт возможности работы со списками-выборками, которых нет в базовом функционале.
В данном случае понадобятся две его возможности:
Рабочий инструмент в JExcel это workbook, создается он на основе Проектов JIRA или сохраненных фильтров. Фильтры написанные на Jira Query Language (JQL) пока не понимает. В каких то дополнительных настройках не нуждается.
Tempo Planner
Это плагин JIRA которые даёт возможности для ведения ресурсов, детального планирования их работы и расчета доступности.
Этим плагином пользуется Руководитель команды разработки, на основании его данных он предоставляет Менеджерам по продукту информацию о доступности ресурсов на очередной цикл разработки.
Confluence
Это самостоятельный продукт — платформа, которая выступает экосистемой для построения внутреннего портала и базы знаний компании. В контексте планирования используется как Витрина для всех кому нужна актуальная информация о планах разработки на следующий цикл и что было в прошедших.
Так на странице в Confluence выглядит Sprint Backlog и план по выпуску релизов на месяц.
Используется стандартный макрос Jira Issue/Filter macro который выводит в Confluence сохраненные фильтры в JIRA. Это экран настройки отображения фильтра на странице.
Устроен так, что когда информация обновляется в JIRA она обновляется и в Confluence, поэтому страница с планом используется также для мониторинга текущего состояния выполнения плана.
Confluence как и JIRA является платным продуктом.
3 фундаментальные идеи для разработки процесса планирования
Идея Первая
Обычно ситуация выглядит так: Есть Продукт, Команда которая его делает, постоянно пополняющийся Список доработок продукта (Product Backlog). Пополняют его Менеджеры по проектам, Менеджеры по продажам/клиентам. которым нужны доработки по их проектам / клиентам (User Story) в определенный срок. Менеджеры конкурируют между собой за ресурсы и это приводит к тому что:
На рисунке показано, что у нас есть 3 клиентские истории, трудоемкость каждой 1 месяц, делает их одна команда разработки. Из-за постоянного переключения между историями возникают дополнительные затраты на переключение, поэтому все 3 истории сдаются в 4-м месяце.
Это рисунок говорит, что если истории приоритезировать и последовательно реализовать, то они будут реализованы быстрее чем в предыдущем способе организации работ. Зеленые квадраты сверху обозначают поступление выручки от клиентов за выполненные заказы.
Ресурсы конкретной команды лучше фокусировать чем распылять и пока первый заяц не будет пойман, за вторым не гнаться.
Идея Вторая
Чем дольше разрабатывается продукт тем выше вероятность что клиентские требования успеют «протухнуть» за этот срок, что приводит к их актуализации со стороны клиента, изменению технического задания, росту объема работы и приводит опять к удлинению срока разработки или к росту потребности в ресурсах, чтобы выдержать срок. Всё это время Клиент работает без нашего продукта, не получает от него выгоды, а конечная стоимость продукта для него увеличивается. Риск того, что Клиент останется не доволен нами и продуктом растёт.
Чтобы требования не «протухали» и Клиент был доволен, нужно выпускать продукт, за который клиент готов заплатить, как можно раньше. Для этого необходимо клиентские требования разбивать на самодостаточные блоки. Выпустив первый блок и принявшись за второй, мы даем клиенту возможности: накопить опыт использования продукта и выгоду от него, уточнить требования на третий блок и разместить заказ на новые требования, о которых Клиент не подумал до этого или не знал, что будут нужны.
Релиз с одной полезной функцией для Клиента через месяц лучше, чем релиз с десятком функций, но через полгода или год.
Идея Третья
Каждый релиз помимо затрат на разработку полезных функций имеет условно постоянные затраты на свой выпуск: это сборка релиза, разворачивание тестовой среды, регрессионное тестирование…
Представим что у нас 4 продукта и раньше мы выпускали новый релиз по каждому продукту 1 раз в полгода, наши затраты на выпуск релизов равны условным 4 единицам. Если мы решим релизить чаще, например, раз в месяц, руководствуясь Идеей №2, то наши затраты на выпуск релизов станут равны 24 условным единицам.
Из этого следует, что:
Принимая решения о частоте выпуска релизов, необходимо посчитать сколько релизов в месяц мы можем физически выпускать сейчас и как изменится итоговая стоимость разработанной функции продукта.
Путь к релизам без стресса
Это видео гарантированно понизит уровень напряжения при подготовке вашего следующего крутого релиза.
Просмотр тем
Лучшим мерилом успеха любой agile-команды является скорость поставки рабочей версии ПО клиентам. Даже опытным командам разработчиков становится не по себе, когда приходит пора проверять, соответствуют ли результаты выполнения задач тем требованиям, что к ним предъявлялись. И выясняется, что где-то была пропущена проверка кода, где-то не выполнили слияние, в сборках после слияния возникают ошибки… Знакомо?
Из этой презентации вы узнаете следующее.
Смотрите и учитесь
Вопросы и ответы
Джейсон Вон и Меган Кук, которые провели эту презентацию, выбрали свои любимые вопросы от зрителей. Прочитайте ответы на них ниже, чтобы узнать, как гарантировать успех релизов, не напрягаясь.
Вопрос 1. Назовите три главных преимущества использования центра управления релизами, помимо технических.
Ответ 1. (1) Уверенная поставка продукта. Заинтересованные стороны в команде и за ее пределами смогут в любой момент цикла релиза узнать, что именно готово к выпуску.
(2) Экономия времени, более быстрое принятие решений. Информация о готовых к поставке функциях и проблемах выдается автоматически за считаные минуты. Центр управления релизами сам проверяет все задачи в выпускаемой версии, чтобы вам не нужно было вручную приводить в соответствие задачи и код.
(3) Учет релизов. Узнать, что вышло (когда и в каком релизе), можно в списке выпущенных версий. Информация о том, что планируется в данный момент для каждого из будущих релизов, содержится в списке невыпущенных версий.
Вопрос 2. Кто обычно управляет версиями релизов в Atlassian?
Ответ 2. У каждой команды в Atlassian есть свой особый подход. При этом мы обычно стремимся максимально автоматизировать процесс, чтобы выпустить исправления багов рабочей версии или новую версию продукта мог любой разработчик команды, приложив минимум усилий.
Обычно команды ведут список актуальных задач, но мы всеми силами пытаемся отказаться от этого. Такой инструмент, как центр управления релизами, очень в этом помогает. Он гарантирует, что версия, которую мы планируем выпустить, будет наивысшего качества и что стадии процесса, на которых находятся задачи в Jira Software, точно отражают их фактическое состояние.
В некоторых командах покрупнее (например, в командах разработчиков Jira Software и Confluence) заведено, чтобы всеми релизами поочередно управляли несколько менеджеров по релизам.
Когда дело касается крупных основных и вспомогательных версий, обычно за релиз отвечает специально назначенное лицо, которое следит за объемом работ, управляет рисками, угрожающими подготовке релиза, и планирует график. Этим может заниматься руководитель команды или руководитель по разработке, но мы стараемся, чтобы каждый участник команды поочередно принимал на себя эту обязанность. Так каждый знакомится с процессом и начинает понимать, какие требования предъявляются к выпуску качественного ПО.
При составлении графика работы руководители команд общаются с менеджерами по продукту и маркетологами, чтобы сформировать ожидания о сроках готовности релиза и понять, нужно ли менять объем или временные рамки работы. Именно эти люди решают, какие функции будут выпущены в рамках тех или иных версий.
Вопрос 3. Каким образом вы устанавливаете связь между веткой/коммитом/запросом pull/сборкой/развертыванием и задачей?
Ответ 3.
1. Ветка — ключ задачи добавляется в имя ветки.
2. Коммит — ключ задачи указывается в комментарии к коммиту.
3. Запрос pull — ключ задачи указывается в имени исходной ветки, добавленном комментарии к коммиту или заголовке запроса pull.
4. Сборка — ключ задачи указывается в добавленном комментарии к коммиту.
5. Развертывание — ключ задачи указывается в добавленном комментарии к коммиту.
Вопрос 4. Как вы обычно устраняете конфликты, возникающие при работе над одним и тем же кодом в отдельных ветках задач?
Ответ 4. Мы редко сталкиваемся с подобной проблемой. Большинство задач предполагает работу над разными фрагментами кода, но иногда конфликты все же возникают.
Все потенциальные проблемы можно поделить на два типа.
Для решения проблем первого типа рекомендуется вести поэтапную разработку и выполнять слияния часто, но сами новые функции вводить через специальные флаги, чтобы доступ к актуальным изменениям имели только сотрудники компании или избранные клиенты. Благодаря этому код, в котором могут возникать конфликты, будет внедряться постоянно, вероятность возникновения конфликта уменьшится, равно как и риск, и негативные последствия, связанные с добавлением крупных функциональных изменений в основную ветку разработки.
Если это невозможно, а также в случае крупномасштабного рефакторинга мы стараемся как можно чаще сливать ветвь разработки в функциональную ветку (передавая изменения в основной ветке/ветке разработки в функциональную ветку). Тогда вся текущая работа по разработке продолжается, и основная ветка приводится в соответствие с долгосрочной функциональной веткой с максимально возможной частотой. При возникновении конфликтов слияния авторам изменений будет гораздо проще помочь решить их или по крайней мере их работа будет сведена к минимуму, чтобы решить конфликты было проще.
Идеальное решение — делить всю работу на части, которые можно было бы сливать в основную ветку как можно чаще. За счет этого уменьшается вероятность, что одни и те же файлы в функциональных ветках изменяются одновременно.
Вопрос 5. Какой стратегии следует придерживаться при управлении параллельными ветками текущей разработки (функциональными ветками), ветками исправлений и их развертывании в различных средах (в среде контроля качества, промежуточной и рабочей средах)?
Ответ 5. В нашем арсенале есть несколько стратегий управления ветками, которые описаны на нашем веб-сайте, посвященном Git. В частности, рекомендуем заглянуть в раздел «Сравнение процессов».
Подробную информацию можно получить, просмотрев запись предыдущего выступления Правильный подход к Git. Рабочие процессы непрерывного развертывания были подробно рассмотрены на вебинаре Рабочие процессы Git для SaaS-команд.
Если коротко, существует два основных рабочих процесса: рабочий процесс для выпуска загружаемых продуктов и рабочий процесс для онлайн-сервисов (рабочие процессы Git для команд, выпускающих программное обеспечение как сервис (SaaS))
Для выпуска загружаемых продуктов большинство команд пользуется вариациями модели Gitflow Workflow, в которой текущая разработка ведется в главной ветке, а каждой предыдущей промежуточной версии соответствует отдельная ветка, от которой отходят (и впоследствии с ней сливаются) ветки исправлений. При необходимости выполняется сборка релиза с исправлениями. Все изменения в каждой предыдущей ветке релиза включаются в последующие ветки релиза и главную ветку, чтобы ни одна из последующих версий не была выпущена без исправлений.
Вопрос 6. Удобно ли использовать центр управления релизами при использовании доски Kanban и частом выпуске релизов?
Ответ 6. Да, вполне. Кнопку Release (Выпустить) на доске Kanban можно использовать для создания новой версии, в которую включаются все задачи, запланированные для этого релиза. После создания версии в центре управления релизами можно просмотреть предупреждения (при наличии) или получить общее представление о версии.
Даже при работе без доски kanban можно в любой момент создать версию и добавить в нее задачи, даже если они еще не завершены. После этого в центре управления релизами можно просмотреть, есть ли предупреждения. Если их нет, значит, релиз готов.
Вопрос 7. Можно ли просматривать в центре управления релизами информацию о задачах из нескольких проектов Jira Software, или в нем всегда отображается информация только по какому-то конкретному проекту и версии исправления?
Ответ 7. В центре управления релизами имеется подробная информация о версии. Поскольку в настоящее время версии относятся к одному определенному проекту, центр управления релизами также соотносится с одним определенным проектом.
Вопрос 8. Можно ли настроить центр управления релизами так, чтобы предупреждения автоматически передавались в комнату Hipchat?
Ответ 8. На данный момент интеграций, которые связывали бы предупреждения центра управления релизами с Hipchat, не существует, и пока что их разработка не планируется. Были разные идеи о том, как расширить возможности командной работы в Hipchat с помощью центра управления релизами. Мы приглашаем наших клиентов поделиться мыслями о том, как они могли бы использовать подобную интеграцию, равно как и любые другие интеграции с другими нашими продуктами.
Вопрос 9. Для чего нужна кнопка Release (Выпустить)? Она запускает сценарий для развертывания релиза на рабочем сервере в виде задачи в Bamboo?
Ответ 9. Кнопка Release (Выпустить) выполняет несколько функций.
Вопрос 10. Планируете ли вы интеграцию центра управления релизами с GitHub/GitHub Enterprise?
Ответ 10. Центр управления релизами уже можно использовать с GitHub и GitHub Enterprise. Для этого нужно подключить экземпляр Jira Software к аккаунту GitHub, нажав DVCS Accounts (Аккаунты распределенных систем управления версиями) в меню администратора аддонов в Jira Software. После этого можно начать отслеживать состояние любой версии, так как вся соответствующая информация о разработке появится в центре управления релизами.
Лаура — бывший менеджер по маркетингу продуктов. У нее есть опыт работы с различными командами по продуктам, включая Jira Software, Portfolio for Jira и Bitbucket. Когда она не занимается разработкой рекомендаций по использованию методик agile, ее можно встретить в горах — во время штурма очередного перевала или при попытке отыскать удобный уступ.
Подпишитесь и получайте больше статей
Thanks for signing up!
Изучите версии с помощью Jira Software
Узнайте, как использовать версии для организации рабочего процесса с разбивкой на практически достижимые контрольные точки. Узнайте, как назначать задачи в проекте в соответствии с определенной версией.
Как ускорить процесс контроля качества
Узнайте, как небольшая команда специалистов по содействию в обеспечении качества агитирует за применение методов сбалансированного тестирования в команде разработчиков и обучает их этим методам.