Often you don’t need all the configurations of an app per stage; sometimes they are optional. This is often the case for the development stage in particular.
Bicep supports conditions by default, but in many examples they are not really well described or even readable. Here is a snippet of how I usually do it:
1// sample param, empty string as fallback
2param corsOption string = ''
3
4// required web app settings
5var requiredWebAppSettings = [
6 {
7 name: 'CosmosDB__Endpoint'
8 value: cosmosAccount.outputs.endpoint
9 }
10 {
11 name: 'CosmosDB__Database'
12 value: db.outputs.name
13 }
14]
15
16// optional entry for cors
17
18var optionalWebAppCorsConfig = corsOption != '' ? [
19 {
20 name: 'CorsOptions__Origins'
21 value: corsOption
22 }
23] : []
24
25
26// create web app config
27module backendApp './modules/app-service-webapp-linux.bicep' = {
28 name: 'deploy-${backendAppName}'
29 params: {
30 name: backendAppName
31 location: location
32 environmentVariables: concat(appApiEnvVarsCollection, appApiCorsOptionsOriginsSection)
33 }
34}
Thanks to concat we have an array with mandatory variables that must always be set and an array with optional cors settings that are only set if the corsOption parameter is not empty. This is now very easy to control, for example with variables in Azure DevOps.
Author
BEN ABT
Ben is a Principal Software Engineer at Medialesson.de, with a strong focus on .NET and Microsoft Azure. In his professional role, he designs and builds highly scalable platforms for hybrid and cloud-based scenarios. He also advises companies and C-levels on migrating to the sovereign cloud.
He runs myCSharp.de, the largest and most active German-speaking C# community forum, actively contributes to both his own and external open-source projects, and regularly shares his knowledge through his blog, at community events, conferences, and as a writer for technical magazines.
Comments