Laden...

Azure Devops: Automatische Notifications erhalten, wenn ein neuer Build mit Artifact vorhanden ist.

Erstellt von dr4g0n76 vor 3 Jahren Letzter Beitrag vor 3 Jahren 1.449 Views
dr4g0n76 Themenstarter:in
2.921 Beiträge seit 2005
vor 3 Jahren
Azure Devops: Automatische Notifications erhalten, wenn ein neuer Build mit Artifact vorhanden ist.

Wir haben gerade die Herausforderung bei uns im Projekt, dass wir Notifications brauchen,
wenn auf Azure ein neuer Build vorliegt, der die Artefakte enthält.

Die sollen dann von einem Programm empfangen werden (Console Anwendung), die dann den Build auf den Rechner lokal herunterlädt.

Jetzt ist die Frage, wie wir das machen können.

Dazu bisher meine Recherchen:

Folgendes habe ich dazu (bisher) in Betracht gezogen, weil ich denke dass eine der Kategorien zumindest helfen sollte diese Notifications/Events zu empfangen.

Also entweder ginge das vermute ich über:

  • Azure Functions
  • Azure Notification Hubs
  • Azure Web Hooks (bisher sieht mir das am vielversprechendsten aus)

Hier gibt's ein Beispiel das helfen könnte:

https://andrewlock.net/creating-my-first-azure-functions-v2-app-a-webhook-and-a-timer/

Was ebenfalls möglich wäre, als Notlösung:

In bestimmten Abständen pollen.
Mit Rest API den letzten Build holen ()

Wie würdet ihr das angehen?

ich werde auf jeden Fall versuchen das zu lösen und dann wie immer die Lösung hier posten.
und dann davon den Artifact herunterladen.

Seit der Erkenntnis, dass der Mensch eine Nachricht ist, erweist sich seine körperliche Existenzform als überflüssig.

16.807 Beiträge seit 2008
vor 3 Jahren

dass wir Notifications brauchen,
wenn auf Azure ein neuer Build vorliegt, der die Artefakte enthält.

~~.. von was genau sprichst Du?

Sofern Du Projektrechte hast kannst Du doch einfach über die persönlichen Settings Notifications verwalten.
Oben Rechts auf das Männchen mit Stirnrad -> Notifications.~~

Okay, jetz verstanden.

Du kannst in AzDo direkt WebHooks ausführen: Create a service hook with WebHooks

dr4g0n76 Themenstarter:in
2.921 Beiträge seit 2005
vor 3 Jahren

Danke @Abt. Der Link zum Ausführen der Webhooks ist sehr hilfreich. 😃
Den kann ich auf jeden Fall brauchen.

Teil a) Was gemacht werden soll

Ich kanns auch nochmal programmatisch erklären:

1.) Programm läuft (Console App), dass die Notification erhält:

Azure Devops hat einen neuen Build der Pipeline mit der ID xyz erfolgreich gebuildet.
Nur dann wird auch eine Notification gesendet, die das Console Programm empfangen kann.

2.) Die Artifakte von der Build Pipeline werden heruntergeladen und entpackt.
3.) Die einzige exe die darin ist wird gestartet. Automatisch.

Grund für das Programm:

Es soll ein vollautomatisches Testsystem erstellt werden,
das immer den neuesten Build mit der exe in Zusammenhang ausführt und testet.

Es soll auch dann funktionieren, wenn keiner da ist.

Teil b) Was gelöst werden muss, damit a) überhaupt für uns machbar wird:

Wie kann man dazu einen Webhook benutzen? Falls das überhaupt der richtige Ansatz ist.
Sollte man überhaupt einen Webhook benutzen?
Es könnte ja auch sein eine Azure Function ist besser?
Oder das Event Grid?

Das bin ich gerade alles am rausfinden und weiss noch nicht, was das beste dabei ist...

Vor allem ob es nicht schon eine Standardnotification gibt, die einfach abgefragt werden kann,
evtl. auch ohne, dass man noch einen neuen Service integrieren muss?

Das weiss ich noch nicht. 😃

Seit der Erkenntnis, dass der Mensch eine Nachricht ist, erweist sich seine körperliche Existenzform als überflüssig.

16.807 Beiträge seit 2008
vor 3 Jahren

Webhooks sind ja "standardisierte Technik". Da ist keine Magic hinter.
Kannst ja nen Doc Deiner Wahl herziehen um zu sehen, wie man sie nutzt.

Wir machen automatisierte Tests über das Release Management bzw. über die Tests Plans; nicht manuell.
Daher kann ich zumindest über den Weg wenig beitragen. Kann Dir nur sagen wie man eben Webhooks in AzD auslöst 😉

T
708 Beiträge seit 2008
vor 3 Jahren

Es soll ein vollautomatisches Testsystem erstellt werden,
das immer den neuesten Build mit der exe in Zusammenhang ausführt und testet

Dann mach doch genau das 😃

Nach dem erfolgreichen Buld, setze einen Docker Container auf und schubse das Programm drauf.
Dann starte die Tests und melde das Ergebnis zurück an DevOps.
Nun lösche den Container wieder.
Alles aus DevOps gesteuert (per PowerShell), wo Du dann auch mit dem Testergebnis direkt weiter machen kannst.

So machen wir das nun schon seit einiger Zeit und ohne das erfolgreiche o.g. Prozedere können wir einen Pullrequest gar nicht abschließen.

Leider habe ich das System selbst nicht aufgesetzt, daher habe ich nur zwei Links parat:
Deploying test environments with Azure DevOps, EKS and ExternalDNS
oder
Docker : .NET Core container automated tests from Azure Pipelines

dr4g0n76 Themenstarter:in
2.921 Beiträge seit 2005
vor 3 Jahren

Webhooks sind ja "standardisierte Technik". Da ist keine Magic hinter.
Kannst ja nen Doc Deiner Wahl herziehen um zu sehen, wie man sie nutzt.

Wir machen automatisierte Tests über das Release Management bzw. über die Tests Plans; nicht manuell.
Daher kann ich zumindest über den Weg wenig beitragen. Kann Dir nur sagen wie man eben Webhooks in AzD auslöst 😉

Ja, das stimmt schon.
Mir fällt noch was anderes gerade ein, was ja auch ginge.
Falls Azure das ermöglicht.

Kennst Du einen Mechanismus, der es erlaubt, dass das Package sofort automatisch von Azure runtergeladen wird, sobald ein Build erfolgreich durchgelaufen ist?
Dann könnten wir auch einen Filewatcher benuzen.

Edit:
Oder wäre das der Buildartifacts Task?

DownloadBuildArtifacts

Geht das auch ohne eigenen lokalen build agent?

Weil wenn das natürlich nur auf den Azure Container runtergeladen wird, bringt das nichts.
Würde das aber lokal runtergeladen, wäre das eine mögliche imho Lösung, die gut genug ist.

Seit der Erkenntnis, dass der Mensch eine Nachricht ist, erweist sich seine körperliche Existenzform als überflüssig.

16.807 Beiträge seit 2008
vor 3 Jahren

Naja, so funktioniert ja weder Azure noch Azure DevOps.
Informationen müssen gepusht werden; Pull gibt es nicht (übrigens auch nicht bei anderen Providern IIRC).
D.h. das Auslösen muss immer aus DevOps passieren.

dr4g0n76 Themenstarter:in
2.921 Beiträge seit 2005
vor 3 Jahren

Dachte ich mir. Denn ich habe auch in diese Richtung nichts gefunden.
Ich bin in dem Fall der Ausführende. 😃 Und muss einfach die Lösungen finden, sollte es nichts geben, dann muss ich das natürlich weitergeben.

Bisher nur Dinge, die eben Notification gehen oder selber herunterladen lassen.

Bisher sieht mir das so aus, als müsste ich trotzdem bei der Lösung bisher bleiben, mit dem selber runterladen. Und mir quasi einen eigenen Event machen.

Ja den Download kann man ja quasi nur auf den Docker Container selbst machen. Was auch Sinn machen kann. Ist halt hier ein anderer Anwendungsfall.

Denn wenn der Build Output erstellt ist,
dann soll lokal ein Test anlaufen mit HW/SW usw. der alles mögliche im Test bereitstellt, damit wir die Qualität garantieren können.

und dafür wird das benötigt. Deswegen muss es eine Custom Lösung in dem Fall sein.

Danke für die Hilfe nochmal.

Auf dem Weg von vorher komme ich auch weiter. 😃

Seit der Erkenntnis, dass der Mensch eine Nachricht ist, erweist sich seine körperliche Existenzform als überflüssig.

16.807 Beiträge seit 2008
vor 3 Jahren

Mh.. vielleicht ist euer lokaler Test einfach suboptimal im generellen Setup?

Wir erstellen für verschiedene Art und Weisen des lokalen Testen (in meinem Fall meistens für die IPCs an Maschinenanlagen) problemlos die Artefakte in Azure DevOps.

D.h.:

  • Virtuelle Maschinen für automatische und manuelle UI Tests
  • Docker Images für Services auf der Maschine
  • IPC Images für manuelles Testen direkt auf der Hardware

zB erzeugen wir vollständige Windows Images automatisiert in Azure DevOps. Die Images werden dann für den SCCM verfügbar gemacht, sodass man an der Maschine via Network Boot automatisch das Image auf den IPC bringt und so dann lokal die Hardware testen kann.
Letzterer Schritt lässt sich bei manchen IPCs sogar ebenfalls automatisieren (über BIOS Settings).