Релизы и автоматические переходы

Задача может двигаться сама: в ревью — когда открыт её merge request, в «выложено на staging» — когда пайплайн её туда выложил, в закрытые — когда вышел релиз, в котором она уехала. Никому не нужно помнить о карточке, а доска показывает, где работа на самом деле.

• Схема статусов со статусом на каждый шаг — готовая «Релизы по стендам» или своя.
• Правила: событие, статус, в котором задача должна стоять, и статус, в который она переходит.
• Вебхук репозитория — чтобы трекер узнавал о ветке и merge request в тот момент, когда они появились.
• Один запрос из пайплайна: что выложено и куда.
• Версии — релизы, в которых задача выходит.

Каждая часть работает и без остальных. Всё на этой странице настраивает лид проекта, из меню ⋯ доски.

1. Откройте доску, затем ⋯ → Статусы и переходы…
2. Нажмите Взять другой… и выберите Релизы по стендам.
3. Если в проекте уже есть задачи, укажите для каждого статуса, в котором они стоят, новый статус.
4. Нажмите Взять Релизы по стендам.

В Закрыто и Отменено можно перейти из любого незавершённого статуса, поэтому работа, которая не едет ни на какой стенд, — рутина, исследование — закрывается оттуда, где стоит. У переходов свои имена («Deploy to Staging», «Preprod verified»), и инструмент читает их в transitions[].name.

Вместе со схемой приходят три стенда — dev, staging, prod — если у проекта их не было, колонка доски на каждый статус, если у доски не было своих колонок, и семь правил, выключенных. Схема становится собственной схемой проекта: дальше её можно править, как любую другую.

Правила приходят выключенными намеренно. Пока вы не включили хотя бы одно, само ничего не двигается — см. следующий раздел.

⋯ → Правила… показывает правила проекта. Семь, которые приходят со схемой:

Включите те, для которых у проекта есть обвязка. Можно написать и свои: любое из этих событий, а также «все подзадачи завершены» и «задача вошла в статус»; правило о merge request можно сузить до ветки, в которую он слит, правило о выкладке — до одного стенда.

• Правило переводит задачу от имени того, кто его включил. В истории задачи написано «правило «…» (от имени Анны)». Если этот человек уходит из проекта, правило выключается само, а не работает с ничьим доступом.
• Это обычный переход. Условия схемы действуют. Если схема перехода не разрешает, с задачей ничего не происходит, а в журнале правила сказано почему.
• «Из» проверяется каждый раз. Задачу не в том статусе, который назвало правило, оно не трогает: merge request, открытый по задаче, которая уже в тестировании, не утащит её назад.
• Считается каждый круг. Задачу, которую вернули и провели заново, те же правила переведут и во второй раз.
• Переход, сделанный правилом, может запустить следующее правило — не глубже трёх переходов.

Три перехода между ними остаются за человеком, потому что каждый — это суждение: «я это тестирую», «проверку прошло», «на staging всё в порядке».

Сначала репозиторий нужно подключить: ⋯ → Репозитории… (GitLab или GitHub).

1. В Репозитории… нажмите Настроить вебхук у репозитория.
2. Нажмите Сгенерировать и скопируйте Адрес и Секрет — секрет хранится запечатанным и больше не показывается.
3. В GitLab: Settings → Webhooks → Add new webhook. Вставьте адрес в URL, секрет — в Secret token; отметьте Push events и Merge request events.
4. В GitHub: Settings → Webhooks → Add webhook. Вставьте адрес в Payload URL, выберите application/json, вставьте секрет и выберите события Pushes и Pull requests.
5. Сохраните в обоих местах. После этого окно показывает, когда хост слышали в последний раз и что он сказал, — пробная доставка тоже считается.

Задача называется своим ключом — ABC-12 — в имени ветки, в заголовке merge request или в его описании. Переводятся только задачи того проекта, к которому подключён репозиторий.

• Одна и та же доставка, пришедшая дважды — повтор, «Resend», — переводит задачу один раз.
• Всё остальное, что шлёт хост (обновление, одобрение, тег), принимается и пропускается.
• В журнале доставок хоста виден наш ответ: 200 с outcome — taken, duplicate, ignored, wrongRepository, disabled — или 401, если секрет не от этого репозитория.

Без секрета репозиторий не принимает ничего. Тип содержимого form-encoded у GitHub отклоняется: выберите application/json.

⋯ → Стенды… хранит стенды проекта по порядку — последний тот, где оказывается готовая работа, — и показывает команду ниже уже с адресом вашего проекта. Шаг пайплайна выполняет её после успешной выкладки:

deploy_staging:
  stage: deploy
  script:
    - ./deploy.sh staging
    - |
      curl -fsS -X POST "https://<workspace>.kaiku.tech/api/projects/ABC/deployments" \
        -H "Authorization: Bearer $PM_TOKEN" -H "Content-Type: application/json" \
        -d "{\"environment\":\"staging\",\"id\":\"$CI_PIPELINE_ID\",\"revision\":\"$CI_COMMIT_SHA\",\"url\":\"$CI_PIPELINE_URL\",\"fromLast\":true}"

PM_TOKEN — маскированная переменная CI/CD с токеном того, кто вправе менять задачи в проекте, — см. Подключение инструмента. Пример — для GitLab CI; подойдёт любой пайплайн, умеющий отправить запрос.

• Сообщается один раз. Тот же id для того же стенда повторно отвечает repeated: true и ничего не делает, так что повтор шага безопасен.
• Ответ перечисляет задачи, которые несла выкладка (issues), ключи, не являющиеся задачами проекта (unknown), сколько раз сработали правила (rulesRan), откуда читался диапазон (from) и — для последнего стенда — unfinished: задачи, которые уехали, но не в завершённом статусе.
• Для диапазона репозиторий должен быть подключён; читаются сообщения коммитов: merge-коммит называет ветку, squash-коммит несёт заголовок запроса. Если репозиторий не ответил, запрос завершается с 502 и ничего не записывается — запустите шаг ещё раз.
• С fromLast первое сообщение о стенде диапазон не читает: до него ничего нет. Оно записывает, откуда начнётся следующий.
• Стенд или версия, которых у проекта нет, — отказ с 400, а не тихий пропуск.

Используйте fromLast, а не переменную CI «предыдущий коммит». Она совпадает с последним выложенным коммитом, только если выкладывает каждый пайплайн; один отменённый или упавший пайплайн — и его задачи так и не узнают, что уехали.

• На задаче есть строка Где лежит со всеми стендами, до которых она дошла; каждый открывает пайплайн, который её туда выложил. Задача на prod по-прежнему говорит и staging.
• В её истории — одна строка на стенд, «выложено на staging», сколько бы раз её туда ни выкладывали.
• На доске есть фильтр Лежит на.
• Задача на последнем стенде, которая не завершена, говорит об этом в строке Где лежит, пока это так.
• В API это поле deployedTo, рядом со стандартными; в поиске оно возвращается, когда запрошено по имени.

⋯ → Релизы… показывает версии проекта с датами и прогрессом. Задача может быть в нескольких — по версии на каждый срез на staging, например, — и задаются они строкой Релиз на задаче.

• Выпустить отмечает версию выпущенной. Если в ней осталась незавершённая работа, экран сначала спросит: оставить её или перенести в версию, которая ещё впереди.
• Выпуск запускает правило «версия выпущена» для каждой задачи, которая осталась в версии. Задача, снятая с релиза, в который не попала, не переводится.
• В поиске: fixVersion = "2.4.0", fixVersion in releasedVersions(), fixVersion in unreleasedVersions().
• В API версия — стандартный ресурс /rest/api/2/version, а версии задачи — её fixVersions; задача берёт только версии своего проекта.
• Пайплайн может класть задачи в версию прямо при выкладке: поле version выше.

Вебхук, который вы зарегистрировали, слышит и версии: jira:version_created, jira:version_updated, jira:version_released, jira:version_unreleased, jira:version_deleted.

• Правило не может сменить исполнителя — только перевести задачу, добавить чек-лист или передать задачу агенту.
• Сообщённую выкладку нельзя отозвать. Ошибочное сообщение исправляется следующим на тот же стенд.
• Условия поиска «лежит на» нет; доска фильтрует свои карточки.
• Вебхуку, который вы зарегистрировали, о выкладках не сообщается.
• Готовая схема берётся на экране; MCP-инструмента для схемы статусов проекта нет.
• Проект, зеркалируемый из другого трекера, сообщений о выкладках не принимает: его задачи живут там.