Релизы

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

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

Суть в двух словах#

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

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

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

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

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

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

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

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

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

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

Значение статусов#

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

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

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

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

1. В разделе Среды выполнения, добавьте нужные этапы и задайте их порядок, например Staging перед Production.

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

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

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

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

Отгрузить спланированную работу#

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

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

Объединить открытые запросы на объединение#

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

1. Выберите Новый релиз, выберите проект и укажите Открытые задачи. Для использования этой опции требуется репозиторий GitHub или GitLab, поэтому в проектах, размещённых на платформе Coroid, релиз формируется на основе конкретного коммита.
2. Coroid сначала группирует открытые задачи в одну ветку развертывания — это самый безопасный вариант. Задача или план, созданные Coroid, отображаются как элемент pull request. Coroid учитывает данные провайдера и результаты собственного рецензирования: параметры проверок, отзывов, размер файлов, наличие конфликтов, а также список файлов, затрагиваемых несколькими задачами. При этом черновики, задачи с непройденными проверками, задачи с запрошенными правками и задачи из форков исключаются из обработки, а причина исключения указывается явно.
3. Снимите отметку с тех задач, которые нужно отложить, и используйте стрелки для изменения порядка. Задача, зависящая от другой (стековая задача 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 также поддерживаются, но ваш провайдер не помечает исходные пулл-реквесты как объединённые. Coroid закрывает их с добавлением комментария.

Отгрузить то, что находится в основной ветке#

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

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

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

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

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

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

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

Через чат или вашу среду разработки#

Чат-ассистент и сервер MCP Coroid предоставляют одинаковые инструменты для работы с релизами: просмотр и анализ релизов, выбор коммита, предварительный просмотр того, что будет выпущено, подготовка релиза, сгруппировка открытых пулл-реквестов, запуск проверок, утверждение релиза, запрос на развертывание и черновики заметок. Для сгруппирования, утверждения и развертывания всегда требуется подтверждение человека. Подробнее в Чат-ассистент и Сервер MCP Coroid.

Совместное развертывание нескольких проектов#

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

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

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

Связанное#

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