Релизы

Эта платформа преобразует задачи и планы в проверенные pull request релиза. После их слияния релиз отвечает на следующий вопрос: какая часть выполненной работы запущена где и можно ли было её туда поместить безопасно?

Релиз привязывает конкретный коммит Git и отслеживает его перемещение по вашим средам, например, тестовой и затем рабочей. Этот коммит уже может находиться в вашей ветке развертывания, либо Coroid сначала объединит открытые pull request в один pull request релиза, чей коммит слияния станет релизом. На каждом этапе Coroid проверяет коммит, собирает требуемые вами подтверждения и фиксирует информацию о развертывании, которую сообщает вам CI/CD. Coroid никогда не помечает релиз как развернутый на основании собственных данных. Ваши конвейеры или человек, фиксирующий внешнее развертывание, должны подтвердить это.

Суть в одну минуту#

• Релиз: один коммит, имя и необязательная версия. Версия вроде 2.4.0 является необязательной, поэтому непрерывная поставка возможна и без тегов.
• Среда: промежуточный этап перед попаданием продукта к пользователям, например тестовая или рабочая среда. Каждый проект определяет собственные этапы и их порядок.
• Развертывание: в каких средах релиз уже достигнул цели.
• Работа: задачи, запланированные для релиза, и внесенные изменения, отображаемые в виде выполненного объема от общего числа.
• Четыре шага для каждой среды: Проверки, утверждение, развертывание и проверка состояния. Страница релиза всегда открывается на шаге, требующем вашего вмешательства.
• Формирование пакета: релиз, созданный из открытых pull request. Coroid объединяет их в одну ветку релиза в порядке, который вы можете изменить, и открывает один pull request релиза. У сводного релиза есть пятый шаг — Формирование пакета, перед этапом Проверки.

Быстрый обзор релиза#

Открыть Релизы в главном боковом меню для любого проекта или вкладку Релизы для конкретного проекта. В процессе выполнения, расположенная вверху, показывает версию, запущенную в каждой среде по результатам последнего подтвержденного развертывания, а также того, кто его инициировал. В списке отображается прогресс работы над релизом, его развертывание по средам и текущий статус. Используйте вкладки, чтобы переключаться между релизами, которые находятся в процессе, уже отправлены в эксплуатацию или закрыты.

Выберите релиз, чтобы открыть его страницу.

Траектория развертывания также служит переключателем. Выберите среду на ней, чтобы увидеть четыре шага для этой среды. Страница открывается на первой среде, которую релиз еще не достиг, поэтому следующее действие обычно уже видно.

Четыре шага для каждой среды#

Проверки. Выберите Запустить проверки. Coroid запускает граф качества релиза проекта для точного коммита и подтверждает, что все связанные изменения входят в этот коммит. Все обязательные пункты чек-листа для данной среды также должны быть отмечены как выполненные. Если что-то блокирует релиз, в шаге будет указано, что именно. Изменение коммита или связанных изменений делает предыдущие проверки устаревшими, и шаг потребует их повторного запуска.

Утверждение. После прохождения проверок лица, разрешенные вашими правилами, могут утвердить релиз. В шаге указывается количество необходимых утверждений и роли, от которых они должны исходить. Если ваши правила требуют утвержденных примечаний к релизу, они также утверждаются на этом этапе.

Развертывание. Когда проверки и утверждение завершены, релиз готов к развертыванию в среде. Если Coroid подключен к GitHub Actions или GitLab CI/CD для данной среды, Владелец или Администратор выбирает Развернуть в… и Coroid запускает конвейер для этого точного коммита. В противном случае ваш конвейер развертывает продукт самостоятельно и сообщает о результате. В любом случае шаг становится зеленым только после подтверждения успешного завершения.

Проверка состояния. После успешного развертывания Coroid запускает канареечный граф качества проекта, если он у вас есть. Успешная проверка канареечного графа означает, что среда в исправном состоянии. При его сбое отображается Требует внимания и предлагается вариант восстановления. Если канареечный граф отсутствует, состояние остается неизвестным, а не считается исправным по умолчанию.

Что означают статусы#

Готово Это никогда не означает развертывание. Только подтвержденное развертывание позволяет продвинуть релиз вперед по траектории выпуска.

Рабочие процессы#

Настройте релизы для проекта#

Сделайте это один раз на проект. Откройте Релизы, выберите Параметры релиза, и выберите проект.

1. В Среды, добавьте свои этапы и расставьте их в порядке, например Тестирование перед Продуктивной средой.

2. В Правила утверждения, опубликуйте правила для каждой среды: сколько утверждений требуется, из каких ролей они должны поступать и какие пункты чек-листа применяются. Среда не сможет пройти проверки, пока правила не будут опубликованы.

3. В Конвейер развертывания, выберите, будет ли Coroid запускать развертывания или это сделает ваш конвейер. Затем создайте токен отчетности, чтобы ваш CI/CD мог сообщить Coroid о том, что было развернуто.

4. В Версионирование, выберите, откуда берется версия каждого релиза, и укажите для каждой среды URL версии, чтобы Coroid мог подтвердить, что там запущено.

Параметры релиза Пошагово объясняет каждый экран, и Укажите версию в сборке Показывает, как версия попадает в ваше приложение.

Выпуск запланированных задач#

Используйте этот вариант, когда заранее известно, что должно выйти вместе.

1. Создайте релиз заранее, до фиксации коммита. Он начинается как черновик.
2. Установите целевой релиз для задач, которые вы хотите включить в него. Они отображаются в Запланированные задачи, и индикатор выполнения заполнится по мере завершения задач.
3. Когда задачи будут объединены, выберите Редактировать детали и выберите коммит для выпуска. Coroid подтвердит, какие объединенные изменения содержит этот коммит.
4. Пройдите через четыре шага для первой среды, затем для следующей.

Объединить открытые pull request'ы#

Используйте этот вариант, когда ожидается множество pull request'ов — от Coroid или от вашей команды, — и они должны быть выпущены вместе.

1. Выберите Новый релиз, выберите проект и укажите Открытые pull request'ы. Для этого варианта требуется репозиторий GitHub или GitLab, поэтому в проектах, хостинг которых осуществляется Coroid, выпускается коммит.
2. Coroid перечисляет открытые запросы на слияние в ветку развертывания, начиная с самых безопасных. Запрос на слияние, открытый Coroid от имени pull request, отображается как задача или план. Coroid учитывает известные провайдеру и результатам собственного рецензирования факторы: проверки, рецензии, размер, конфликты и файлы, затронутые несколькими запросами на слияние. Он исключает черновики, проверки с ошибками, запросы на изменения и запросы на слияние из форков, а также указывает причины.
3. Снимите отметку с тех элементов, которые нужно отложить, и используйте стрелки для изменения порядка. Pull request, основанный на другом (stacked pull request или такой, в описании которого указано «зависит от #12»), всегда идет после него.
4. Выберите Создать релиз. Coroid создает release/<version> из ветки развертывания, объединяет pull request'ы в указанном порядке и открывает один pull request релиза, в котором перечислены и ссылки на каждый из них.
5. Если pull request вступает в конфликт с веткой релиза, Формирование пакета шаг останавливается, и отображаются затронутые файлы. Выберите Решить с помощью Coroid чтобы агент-разработчик объединил изменения и разрешил конфликт в рамках задачи, или Оставить вне чтобы продолжить без него.
6. Рецензируйте pull request релиза и объедините его с помощью коммита объединения. Ваш провайдер затем пометит все объединенные pull request как объединенные. Coroid зафиксирует коммит объединения как коммит релиза, зарегистрирует объединенные pull request'ы как часть выпуска и закроет все еще открытые задачи со ссылкой на pull request релиза.
7. Пройдите через четыре шага для каждой среды, как обычно.

Методы объединения типа squash или rebase также работают, но ваш провайдер не помечает исходные pull request'ы как объединенные. Coroid закрывает их с помощью комментария.

Выпуск того, что находится в главной ветке#

Используйте этот вариант для непрерывной доставки, когда выпускается всё, что было объединено.

1. Выберите Новый релиз и выберите коммит, обычно последний в ветке развертывания.
2. В разделе Сравнить с, выберите среду, которую вы собираетесь заменить. Coroid перечислит pull request'ы и коммиты между текущей версией и вашим коммитом и отберет те, которые может проверить.
3. Можно оставить название и версию пустыми. Coroid присвоит релизу название на основе даты и короткого коммита, а источник версии проекта заполнит поле версии. Каждому релизу также присваивается следующий номер сборки.
4. Создайте релиз и следуйте четырем шагам.

Если ваш конвейер запускает развертывание при каждом слиянии или кто-то развертывает вручную, не уведомив Coroid, он всё равно сможет зафиксировать каждое развертывание. Если для указанного коммита нет pull request релиза, Coroid создаст для него зарегистрированный релиз, четко помеченный как не прошедший проверки Coroid. Версия будет взята из данных конвейера, а если Coroid сам назначает версии проекта — следующая по порядку (1.4.1 после 1.4.0), и следующим номером сборки.

Отправить срочное исправление#

Владелец или администратор может включить Это хотфикс при создании релиза: прикрепите полный хэш коммита с исправлением и укажите причину, по которой стандартные сроки не подходят. Хотфиксы подчиняются правилам для хотфиксов в каждой среде, что может предусматривать меньше этапов согласования. Проверки качества и обязательные пункты чек-листа остаются в силе, а согласовывать хотфиксы могут только владельцы и администраторы.

Восстановиться при сбое#

Если шаг проверки состояния показывает Требует внимания, откройте Состояние в соответствующей среде и выберите более ранний корректный коммит для повторного развертывания. Восстановление и релизные составы описывает доступные варианты, включая конвейеры, которые не могут отправлять отчеты о статусе.

Из чата или вашего редактора#

В чат-ассистенте и сервере MCP Coroid доступны одинаковые инструменты для работы с релизами: просмотр и анализ релизов, выбор коммита, предварительный просмотр того, что будет отправлено в продакшен, подготовка релиза, объединение открытых pull request релиза, запуск проверок, согласование релиза, запрос на развертывание и черновики примечаний. Для объединения, согласования и развертывания всегда требуется подтверждение человека. Подробнее — в Чат-ассистент и Coroid в роли сервера MCP.

Релиз нескольких проектов одновременно#

Релизный состав объединяет релизы из нескольких проектов, которые должны выпускаться вместе и по порядку, например, API и приложение, зависящее от него. Подробнее — в Восстановление и релизные составы.

Что делает и чего не делает Coroid#

• Coroid фиксирует, проверяет и регистрирует данные. Ваш репозиторий и CI/CD занимаются сборкой и развертыванием.
• Когда он объединяет запросы на слияние, Coroid создает ветку релиза и pull request релиза. Он никогда не сливает pull request релиза за вас.
• Coroid запускает конвейер только после того, как вы его подключите, а владелец или администратор запросит развертывание.
• Запрос на развертывание — это не доказательство успешности. Трек релиза сдвигается только после подтверждения успеха конвейером или когда кто-то зафиксирует подтвержденное внешнее развертывание.
• Примечания к релизу — это черновики, которые вы редактируете и согласовываете. Coroid нигде их не публикует.
• Спринт — это период планирования, а не граница развертывания. Один спринт может быть основой для нескольких релизов, а один релиз может включать работу из нескольких спринтов.

Связанное#

• Настройки релиза
• События развертывания и настройка CI
• Укажите версию в сборке
• Восстановление и релизные составы
• Спринты
• Задачи, планы, спринты и колонки
• Качество и подтвержденные данные проверки