TL;DR
Azure DevOps Release Pipeline mit Azure Container Registry als Artifact und Release Trigger bei docker-push

Es gibt ja bekanntlicherweise Fälle in denen die eigentliche Entwicklung nicht durch das eigene Team oder sogar durch die eigene Abteilung übernommen wird. Vielleicht haben die Entwickler sogar eigene Repositories, Build Server und what-nots. Was also tun um solche Fälle in die eigenen Release Pipelines zu übernehmen, ohne den Entwicklern ihre bekannte Umgebung wegzunehmen?

Der berühmte Spruch „Es führen viele Wege nach Rom“ trifft hier (leider) auch zu! Natürlich wäre es möglich aus der Nase, durch das Auge und wieder zurück am Ende am Ziel anzukommen, der einfachste Weg aber ist meiner Meinung nach der Weg über die ACRs (Azure Container Registries).

Wat? Wie? Wo? Wovon redet der da? Fragen sich vielleicht einige jetzt.

Die Release Pipelines in Azure DevOps akzeptieren verschiedene Artefakte/Quellen für ein Release, darunter auch Azure Container Registry.

Das Problem daran? Der Eintrag ist minimal versteckt.

Wenn man den Typ ACR als Quelle ausgewählt hat, war das schon die halbe Miete. Danach müssen nur noch die Service Connection, Ressourcen Gruppe und Name der ACR selbst ausgewählt werden und man hat die Auswahl der Docker Repositories (Image Namen) welche dieses Release triggern sollen.

Zum Abschluss wollen wir natürlich auch das unser Release automatisch getriggert wird wenn für das Docker Image eine neue Version verfügbar ist, also klicken wir auf das Blitzsymbol und aktiveren auf der rechten Seite das automatische triggern des Releases.

Das einzige was sich für die Entwickler jetzt ändern könnte, ist die Registry in die das Image gepusht wird, sofern nicht bereits eine ACR im Einsatz ist.