Benachrichtigung an alle Entwickler senden, wenn eine Veröffentlichung in VSTS fehlschlägt (vorher VSO)

Question

Ich verwende Visual Studio Team Services (VSTS), früher als Visual Studio Online (VSO) bekannt, um eine Continuous Delivery-Pipeline zu erstellen. Mein Ziel ist es, so nah wie möglich das Buch Continuous Delivery von Jez Humble und David Farley zu folgen.

Ich möchte, dass wenn eine Phase (namens Umgebung in VSTS) fehlschlägt, eine Benachrichtigung (eine E-Mail) an alle Entwickler in dieser Version beteiligt gesendet wird. Diese Meldung würde entweder sagen:

• Sie die Bühne brach (Regression)
• Die Bühne bereits gebrochen wurde (fehlgeschlagen)
• Sie die Bühne fixiert. (Fixed)

Derzeit ist nur die Person, die die Freigabe manuell erstellt (oder durch Drücken der Commit, die die Build ausgelöst und danach die Freigabe) wird diese E-Mail erhalten und ohne die Informationen, die ich will.

ich ein wenig mit VSTS API gespielt haben, und die damit verbundenen Commits (und die Entwickler E-Mail) für einen bestimmten Build (aber nicht für eine bestimmte Freigabe) erhalten:

$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 } 

Ich habe gesehen, dass in VSTS-Schnittstelle können Sie sehen, welche Commits zwischen 2 Releases hinzugefügt wurden. Es ist sehr nahe von dem, was ich möchte, auch wenn ich diese Information nicht in der API gefunden habe. Aber selbst mit diesen Informationen wird für alle Zweige meines Projekts die gleiche Release-Definition verwendet, so dass beispielsweise Release-26 ein Feature-Zweig ist und Release-27 entwickelt wird. Es macht keinen Sinn diese 2 Versionen zu vergleichen.

Ich weiß, dass ich die Build-ID in einer Release-Phase von der Umgebungsvariablen erhalten kann, und danach mein Skript oben und erstellen Sie eine PowerShell-Task oder einen Webservice auf VSTS. Aber es wird nur funktionieren, wenn ein Release für jeden Build ausgelöst wird, was nicht immer der Fall ist.

Kennen Sie eine (bessere) Möglichkeit, diese Benachrichtigungen mit VSTS zu senden?
Und verwende ich das richtige Werkzeug für diese Art von Dingen?

Answer 1

Sie können die E-Mail-Benachrichtigung nur an "Umgebungseigentümer" & "Ersteller der Freigabe" senden und es gibt keine Möglichkeit, den Inhalt in der E-Mail-Benachrichtigung anzupassen. Sie können eine Funktionsanforderung unter VSTS User Voice einreichen.

Rest API ist ein gutes Werkzeug, um diese Informationen zu erhalten. Sie haben jedoch erwähnt, dass Sie für alle Zweige die gleiche Release-Definition verwenden. Das macht keinen Sinn. Verschiedene Zweige beziehen sich auf unterschiedliche Versionen Ihres Projekts. Warum stellen Sie alle in einer Release-Pipeline bereit? Wenn Sie Ihren Workflow pro Zweig auf eine Release-Definition konfigurieren, wäre die Auflösung einfacher. Sie müssen nur die Build-ID für die vorherige Version abrufen und dann die Änderungen nach diesem Build abrufen. Sie können auch eine Powershell-Task hinzufügen, um ein label/tag für TFVC/Git-Repositories für die aktuelle Release-Version zu erstellen, damit Sie die Änderungen zwischen den Labels/Tags erhalten.