Есть ли в VSTS эквивалент Jira-Releases? - PullRequest
Новая
       30

Есть ли в VSTS эквивалент Jira-Releases?

0 голосов
/ 16 ноября 2018

В Jira вы можете создавать релизы для проекта. Как часть выпуска, вы можете указать, какие проблемы являются его частью, а также добавить примечания к выпуску. Они чрезвычайно полезны, когда у вас есть автоматизированные сценарии сборки, так как сценарии API могут запрашивать API для JIRA как часть конвейера CD.
Поэтому вы можете делать такие вещи, как (но не ограничиваясь):

  • Заполнить журнал изменений динамически
  • Остановить развертывание, если в выпуске есть неполадки, которые не выполнены
  • Получить номера версий

Вопрос: существует ли VSTS-эквивалент?

1 Ответ

0 голосов
/ 16 ноября 2018

Я не думаю, что в настоящее время есть что-то, прямо сравнимое с «релизом» Jira, встроенным в Azure Devops, который позволил бы вам упаковать законченные рабочие элементы на доске в рабочий элемент «релиз».

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

Редактировать: В качестве примера методов интеграции REST API для Azure DevOps поддерживает простой запрос REST GET для запроса всех рабочих элементов в проекте для пользовательского типа рабочего элемента:

GET https://dev.azure.com/{organization}/{project}/_apis/wit/reporting/workitemrevisions?types={YourCustomWorkItemType}&includeLatestOnly=true&api-version=4.1

API также будет возвращать любые настраиваемые поля, связанные с этим WIT, перечисляя их под ключом «Custom. {YourFieldName}» в объекте «fields» ответа WIT.

Если ваша команда работала со спринтами, другой потенциальный метод, который я мог бы придумать, состоял бы в том, чтобы каждый «спринт» стал именованной версией, которая стала бы вашим «релизом» после завершения спринта.Рабочие элементы, которые не были реализованы как часть этого спринта / версии / выпуска), затем будут перемещены в следующий спринт или закрыты.Я не уверен, что этот подход был бы очень устойчивым для сложных проектов.

На временной шкале Azure Devops Features есть интересующие функции, которые могут улучшить этот рабочий процесс в ближайшем будущем (длянапример, «Отслеживание выпуска - интеграция рабочих элементов», запланированная к внедрению в четвертом квартале 2018 года, хотя трудно найти какие-либо подробности реализации.

...