Azure Bicep Ressourcennamen in Azure Devops ${uniqueString(resourceGroup().id)

Hallo zusammen,

wie erstellen mit bicep unsere Azure Ressourcen und verwenden die Funktion als Suffix im Namen, um sicherzustellen, dass die Namen eindeutig sind.

Kann ich den Output von ${uniqueString(resourceGroup().id) in einer Azure DevOps Pipeline abrufen? Gibt es einen anderen Weg oder Best Practice? Ansonsten evtl. in Variablen des Azure DevOps Projekts?

Über Hilfe wäre ich sehr dankbar!

Die Best Practise und auch das vorgesehene Verhalten ist, dass Du in Deinem main.bicep entsprechende Outputs hast.

Bicep spuckt Dir diese Werte als Json aus, sodass Du diese weiter in der Pipeline nutzen kannst.
Dazu bietet sich auch an, dass Du ein PowerShell Script nutzt, das Dein Deployment startet.

// main.bicep

output myOutputVar string = 'Hello World'

// PowerShell

$result = az deployment group create -g test --template-file main.bicep | ConvertFrom-Json
$myOutputVar = $result.properties.outputs.myOutputVar.value

Die $myOutputVarkannst Du dann weiter verwenden; im Script entsprechend über die Variablen - in weiteren Steps über dieses wirre Variablen-Handling in Azure Devops.

Write-Host "##vso[task.setvariable variable=myOutputVar;isoutput=true]$myOutputVar"

Vollständiges Sample siehste hier: Using Bicep params and output in Azure Pipelines | by Philipp Bauknecht | medialesson | Medium

Im Endeffekt würde man also über die main.bicep die kompletten Ressourcennamen ( WebApp, DB...) zurück geben; nicht nur den generierten Teil.
So kann man 100% alles dynamisch umsetzen.

Nur als Disclaimer: Ich hab an dem verlinkten Blogartikel mitgeschrieben. Wer den nervigen Medium-Banner sieht - einfach im Inkognito-Modus öffnen.

Danke Abt, ich hab nicht daran gedacht, den Output aus dem Powershell-Aufruf zu verwenden.

Spricht etwas gegen die Speicherung des Outputs in Library\Variable Groups damit ich die Ressourcennamen auch in anderen Pipelines zur Verfügung habe oder gibt es noch eine bessere Lösung?

Das ist relativ; kann ich bzw will ich auch nicht so bejahen oder verneinen - ich verantworte euer Dev(Sec)Ops nicht 😃

Bei uns hat keine einzige Pipeline irgendwo Rechte, etwas in Libs zu schreiben - ist eigentlich auch nicht notwendig.
Die Grundidee ist ja, dass jeder Pipeline ein Deployment hat - teilen sich bei euch zwei Pipelines das gleiche Deployment-Szenario, dann ist das halt nen (begründeter?) Workaround.
Ich bzw. "wir" (Firma, Projekte, Kunden..) halten uns jedoch so streng wie möglich an die optimalen Szenarien von Azure / Azure DevOps.

• Wir haben ein völlig autarkes Bicep-Setup, das die Infrastruktur aufsetzt.
• Alle Azure DevOps Steps bekommen ihre notwendigen Daten durch Bicep-Outputs
• Wir sharen niemals Informationen über Pipelines hinweg; alle Libs sind nur read-only, allein schon aus Berechtigungsgründen

Aber auch wir arbeiten zwangweise bei ein paar Dingen mit Workarounds:

• Wir haben oft zwei main.bicep Files: main-run.bicep und main-read.bicep - wir führen das run-file nur aus, wenn sich was an der Infrastruktur verändert hat (git diff) ⇒ dadurch läuft die Pipeline schneller (je nach Pipeline spart das bei uns 80% der Dauer). Das read-file ist viel kleiner, ändert nichts (alles via existing) und liest die Outputs für die weiteren Steps aus.
• Wir arbeiten bei allen Bicep-Files mittlerweile mit bicepparam-Dateien
• Brauchen andere Pipelines Werte (zB zentrale Komponenten wie Config Service für Feature Flags), dann sind die in den Param-Files hinterlegt oder sie holen sich die Werte eben über existing - das ist ja eben der Vorteil, wenn man über Bicep das dynamische Zeug generieren lässt: man kann immer darauf referenzieren, weil es idempotent ist.

Wenn Du über die Lib gehen willst, musst das selbst verantworten. Ich würde es im Vergleich als die schmutzigere Workaround-Lösung bezeichnen 😉

Die Funktionsweise, die ich hier beschrieben hab, ist so auch für mycsharp.de umgesetzt (wir haben nur noch keine bicepparam-Files, die sind ja noch nicht so lange GA).

Hallo Abt,

vielen Dank für den Einblick - da wir auch mit bicep und Parameterdateien arbeiten werde ich auch ein read bicep File erstellen welches die Infos ausliest. Das denke ich ist dann der beste Weg auch über mehrere Pipelines hinweg. Das read bicep File liest dann die namen über outputs aus und ich kann diese in der Release Pipeline weiter verwenden.

Die Infrastruktur wird auch bei uns komplett über bicep angelegt.