2016-06-14 3 views
4

Я использую Visual Studio Team Services (VSTS), ранее известный как Visual Studio Online (VSO), для построения конвейера непрерывной доставки. Моя цель - следовать как можно ближе к книге Continuous Delivery от Jez Humble и David Farley.Отправлять уведомление всем разработчикам, когда сбой в VSTS (предыдущий VSO)

Я бы хотел, чтобы при сцене (с именем Environment in VSTS) уведомление (электронное письмо) отправлено всем разработчикам, участвующим в этом выпуске. Это уведомление будет говорить либо:

  • Вы нарушили этап (регрессия)
  • Сцена была уже сломана (Failed)
  • Вы исправили сцену. (Фиксированный)

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

Я играл немного с VSTS API, и могу получить связанные фиксации (и разработчик электронной почты) для данной сборки (но не для данного выпуска):

$token = "vsts token" 
$endpoint = "https://acme.visualstudio.com/DefaultCollection/MyProject/_apis/build/builds/42/changes?api-version=2.0" 

$b64creds = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes("$($token):a")) 
$changes = Invoke-RestMethod -Headers @{Authorization="Basic $b64creds"} $endpoint 

$changes.value | ForEach-Object { $_.author.uniqueName } 

Я видно, что в интерфейсе VSTS вы можете видеть, какие коммиты были добавлены между двумя релизами. Это очень близко к тому, что я хочу, даже если я не нашел эту информацию в API. Но даже с этой информацией для всех ветвей моего проекта используется одно и то же определение выпуска, так что, например, Release-26 станет подразделением функций и Release-27. Нет смысла сравнивать эти 2 выпуска.

Я знаю, что я могу получить идентификатор сборки в стадии выпуска из переменной окружения, а затем использовать мой сценарий выше и создать задачу PowerShell или Webservice, подключенную к VSTS. Но это будет работать, только если релиз запускается для каждой сборки, что не всегда так.

Вы знаете (лучший) способ отправки этих уведомлений с помощью VSTS?
И я использую подходящий инструмент для таких вещей?

+0

Надеюсь, в один прекрасный день мы увидим мониторинг выпуска, реализованный в Catlight. Это очень хорошая работа, предупреждающая команду о статусе сборки VSTS, но отслеживания выпуска не существует - http://catlight.helprace.com/i17-add-support-to-release-status – alex

ответ

0

Вы можете отправить оповещение только по электронной почте «Владелец окружающей среды» & «Создатель выпуска», и пока нет возможности настроить контент в уведомлении по электронной почте, вы можете отправить запрос функции на VSTS User Voice.

Rest API - хороший инструмент для получения этой информации. Но вы упомянули, что используете одно и то же определение выпуска для всех ветвей. Это не имеет смысла. Различные отрасли относятся к разной версии вашего проекта, почему вы развертываете их все в одном конвейере выпуска? Если вы настроите свой рабочий процесс на одно определение выпуска на каждую ветку, разрешение будет более простым. Вам просто нужно получить идентификатор сборки для предыдущей версии, а затем получить изменения после этой сборки. Кроме того, вы можете добавить задачу powershell для создания Lable/tag для хранилищ TFVC/Git для текущей версии выпуска, чтобы вы могли получать изменения между ярлыками/тегами.

+0

_ Различные ветви относятся к разной версии ваш проект, почему вы развертываете их все в одном конвейере выпуска?_ Несомненно, я полностью согласен, но мы хотим иметь рабочий процесс git, как описано в статье [«Успешная модель ветвления git»] (http://nvie.com/posts/a-successful-git-branching- модель/). И это связано с созданием множества ветвей. И это единственный способ, которым я знаю, автоматически строить эти ветви. Я не нашел такого варианта, как мультибрендовый трубопровод в дженкинсах. Было бы очень сложно и контрпродуктивно обрабатывать все эти ветви вручную. –

+0

@ Q.Dufour У вас может быть много филиалов во время разработки, но в обычном режиме процесс заключается в том, чтобы объединить все изменения обратно в релизную или ведущую ветвь, когда код в других ветвях стабилен и готов к выпуску. Затем вы можете создавать и разворачивать код в ветви релиза или мастера. И когда вы создаете определение сборки в VSTS с репозиторием Git, вы можете выбрать только одну ветку для определения одной сборки. Но вы упомянули, что определение выпуска для всех филиалов связано с привязкой определения выпуска к определениям сборки сервера? –

+0

Да, мы объединяем все наши ветви функций в разработке/master. Но перед слиянием мы хотим проверить, что весь наш конвейер не сломан, и мы используем Release Management для построения этого конвейера. Он включает в себя наши интеграционные тесты, тесты пользовательского интерфейса, тесты производительности, развертывание в QA и его проверку и т. Д. Таким образом, мы автоматически запускаем выпуск для каждой сборки на каждой ветке, так как мы хотим как можно скорее получить отклики на каждое изменение кода. Возможно, проблема ... –

Смежные вопросы