Lösen Sie nur eine Freigabe aus, wenn sich der Build geändert hat

In den Anfängen, als wir XAML-Builds in TFS verwendeten (wow, das scheint eine Ewigkeit her zu sein!), hatten wir die Möglichkeit, einen Build NICHT auszuführen, wenn sich im Quellcode-Repository nichts geändert hat. Dieses Kontrollkästchen "Bauen, auch wenn sich nichts geändert hat" gibt es in VSTS nicht mehr. Für mich ist das kein wirkliches Problem, denn wenn Sie Ihren Quellcode bauen, ist das auch eine Validierung, ob Ihr zugrunde liegendes System in Ordnung ist. Es ist eher ein Problem, wenn Sie nach einem nächtlichen Build automatisch eine Release-Pipeline auslösen. Warum sollten Sie eine neue Version Ihrer Anwendung freigeben, wenn es sich nicht um eine neue Version, sondern um genau dieselbe Version handelt. Natürlich können wir darüber diskutieren, dass es kein Problem sein sollte, dass Sie immer in der Lage sein sollten, zu veröffentlichen, aber trotzdem. Es ist unnötig und manchmal sogar unerwünscht.

Um dieses Problem zu lösen, habe ich ein kleines Skript und einen Prozess entwickelt, um dieses Problem zu lösen.

• Der Build wird jede Nacht ausgelöst. Ich kann dies nur durch einen manuellen Trigger stoppen.
• In diesem Build prüfe ich, ob die CommitID, die den Build ausgelöst hat, mit der CommitID des letzten erfolgreichen Builds der gleichen Definition übereinstimmt
• Wenn dies nicht der Fall ist, versehe ich mein Build mit einem Tag. In meinem Fall "Release".
• Ich habe meine Veröffentlichungspipeline so eingerichtet, dass nur der Build mit diesem Tag veröffentlicht wird

Das Skript In meinem GitHub Repository finden Sie das gesamte Skript, aber ich werde Ihnen einige Teile erläutern. In diesem Ausschnitt sehen Sie, dass ich zunächst die Details meines aktuellen Builds abrufe. Ich rufe diesen Build anhand seiner ID ab. Diese habe ich aus meiner Build-Pipeline gesendet, wo ich die vordefinierte Build-Variable $(Build.BuildID) verwende.

Dann verwende ich die Build-Definitions-ID, um alle Builds mit der gleichen Definition abzurufen und filtere nur erfolgreiche Builds heraus und nehme die neuesten. Dann überprüfe ich die Quellversion, die die CommitID ist, und prüfe, ob sie gleich ist. Wenn nicht, versehe ich den Build mit einem Release-Tag Richten Sie die Pipeline ein Dann richte ich in der Release Pipeline, die diesen Build bereitstellt, das Trigger-Tag ein, so dass nur Builds mit dem richtigen Trigger freigegeben werden. Das habe ich in meinem früheren Blogbeitrag beschrieben. Das war's! Jetzt können Sie sicher ein geplantes Build erstellen und müssen sich keine Sorgen mehr über doppelte Veröffentlichungen machen! Die vollständige Quelle finden Sie hier!