Intro
I received feedback asking if I could do more DevOps and Bicep articles, so this is the first in a series about this topic. Like most blog series, I will start from scratch and gradually come near a production environment. It can be hard to say this is fully production-ready due to different policies and operations in each customer environment. I will show what it can be, and then it will be up to you if it will fit in your environment or with your customers.
This first article will show how to create a simple Azure App service using Bicep code. I will deploy the App Service using Azure DevOps and GitHub.
App service Bicep code
Creating an Azure App Service requires a few resources. First, you will need an App Service Plan and then the App Service itself. Application Insights is optional, so I leave it out for this first configuration.
Code for App Service Plan
param location string
param projectName string
param skuName string = 'B1'
param skuTier string = 'Basic'
param kind string = 'Linux'
resource appServicePlan 'Microsoft.Web/serverfarms@2023-12-01' = {
name: 'asp-${projectName}'
location: location
sku: {
name: skuName
tier: skuTier
}
kind: kind
properties: {
reserved: (kind == 'Linux') ? true : false
}
}
output appServicePlanId string = appServicePlan.id
Code for the App Service
param location string
param projectName string
param appServicePlanId string
resource appService 'Microsoft.Web/sites@2023-12-01' = {
name: 'app-${projectName}'
location: location
properties: {
serverFarmId: appServicePlanId
}
}
The code above will create the App Service Plan and App Service, but just deploying the two files requires you to grab the App Service Plan ID manually and use it as input for the App Service. Let’s instead change the code above to a module and then call the module. I will save the code below as app_service.bicep
param kind string = 'Linux'
param location string
param project_name string
param sku_name string = 'B1'
param sku_tier string = 'Basic'
resource appServicePlan 'Microsoft.Web/serverfarms@2023-12-01' = {
name: 'asp-${project_name}'
location: location
sku: {
name: sku_name
tier: sku_tier
}
kind: kind
properties: {
reserved: (kind == 'Linux') ? true : false
}
}
resource appService 'Microsoft.Web/sites@2023-12-01' = {
name: 'app-${project_name}'
location: location
properties: {
serverFarmId: appServicePlan.id
}
}
To call the module, I will use a Bicep parameter file called “demo1-devops.bicepparam” and “demo1-github.bicepparam”. Below is the code for the Bicep parameter file.
using '../Modules/app_service.bicep'
param location = 'WestEurope'
param project_name = 'demo1-devops'
Azure DevOps
Repository
In Azure DevOps, I will use the default repository created for the project. I will place my module file in a " Modules " folder and the parameter file under “demo1”.
Pipeline
I will create a pipeline for continuous deployment that runs every time I change the bicep parameter file. I can also run the pipeline manually if needed.
name: Demo1
trigger:
branches:
include:
- main
paths:
include:
- 'demo1-devops.bicepparam'
variables:
- name: DeploymentName
value: 'Demo1'
- name: resourceGroupName
value: 'rg-bicep-devops-demo'
- name: ServiceConnection
value: 'mi-bicep-devops'
- name: TemplateParameterFile
value: 'demo1-devops.bicepparam'
pool:
vmImage: ubuntu-latest
stages:
- stage: Validate
jobs:
- job: Validate
steps:
- task: AzurePowerShell@5
name: Validate
inputs:
azureSubscription: $(ServiceConnection)
ScriptType: 'InlineScript'
Inline: 'Test-AzResourceGroupDeployment -ResourceGroupName $(resourceGroupName) -TemplateParameterFile $(TemplateParameterFile) -Verbose'
azurePowerShellVersion: 'LatestVersion'
pwsh: true
- stage: WhatIf
jobs:
- job: WhatIf
steps:
- task: AzurePowerShell@5
name: WhatIf
inputs:
azureSubscription: $(ServiceConnection)
ScriptType: 'InlineScript'
Inline: 'New-AzResourceGroupDeployment -Name $(DeploymentName) -ResourceGroupName $(resourceGroupName) -TemplateParameterFile $(TemplateParameterFile) -WhatIf -Verbose'
azurePowerShellVersion: 'LatestVersion'
pwsh: true
- stage: Deploy
dependsOn: WhatIf
jobs:
- deployment:
displayName: Deploy
environment: Production
strategy:
runOnce:
deploy:
steps:
- checkout: self
- task: AzurePowerShell@5
name: Deploy
inputs:
azureSubscription: $(ServiceConnection)
ScriptType: 'InlineScript'
Inline: 'New-AzResourceGroupDeployment -Name $(DeploymentName) -ResourceGroupName $(resourceGroupName) -TemplateParameterFile $(TemplateParameterFile) -Verbose'
azurePowerShellVersion: 'LatestVersion'
pwsh: true
To use the pipeline, I need to either add it using the Azure DevOps CLI or create it using the file above using the portal. I will do this article in the portal, but we will revert to using the Azure DevOps CLI to manage Azure DevOps.
Adding the pipeline to Azure DevOps
First, I navigate to Pipelines, and then click “Create pipeline.”
I click on “GitHub” since I use the same repository for the pipeline and GitHub Action. The process for using the Azure DevOps repository is the same.
Next, I search for my repository and select it. In my case “mracket/bicep-DevOps.”
I select “Existing Azure Pipelines YAML file.”
I use the drop-down box to select my yaml file.
Now, I can either run my pipeline or save it. I usually save it by clicking on the small arrow next to “run” and selecting " save."
Azure DevOps uses the repository name as the pipeline name. For me, that doesn’t look good. I can click the menu at the top right and select “Rename/move.”
I name the pipeline “demo1.”
Now, I will run the pipeline, and after a bit, you will most likely see a warning saying, “This pipeline needs permission to access resources before this run can continue to Deploy.” I click on “View” to add these permissions.
I click on “Permit.”
Click on “Permit” again.
After a minute or so, the deployment is complete.
GitHub
Repository
The repository part of GitHub is the same as that of DevOps. The folder structure is the same, so only the use of GitHub service instead of Azure DevOps differs.
GitHub Action
GitHub Actions are equivalent to Azure DevOps Pipelines, and they are also very powerful and support the continuous deployment of services. The code for GitHub Actions is YAML, just like Azure DevOps. The actions used in Github are not the same as those used in Azure DevOps, but they perform the same thing, just another component. GitHub Actions have one significant advance: placing the yaml file in a special folder automatically adds it to GitHub as a workflow.
The code below will perform the same as the Azure DevOps Pipeline we created previously.
on:
push:
paths:
- demo1.bicepparam
branches: main
name: demo1
permissions:
id-token: write
contents: read
jobs:
build-and-deploy:
runs-on: ubuntu-latest
steps:
# Checkout code
- uses: actions/checkout@main
- name: 'Az CLI login'
uses: azure/login@v2
with:
client-id: ${{ secrets.CLIENT_ID }}
tenant-id: ${{ secrets.TENANT_ID }}
subscription-id: ${{ secrets.SUBSCRIPTION_ID }}
- name: Deployment
uses: azure/bicep-deploy@v2
with:
type: deployment
resource-group-name: rg-bicep-devops-demo
operation: create
name: demo1
scope: resourceGroup
subscription-id: ${{ secrets.SUBSCRIPTION_ID }}
parameters-file: demo1.bicepparam
I can now browse to the “Actions” section in GitHub and see that my workflow is present, as well as that it has run a deployment.
App service running
To verify that my deployment worked as expected, I can check the Azure Portal for service status and click the URL for the app service. Below is a screenshot of the service in the Azure Portal, and another is where the service shows the website it is hosting.
Summary
To conclude this first post in the new series about DevOps and Bicep, deploying Bicep with either Azure DevOps or GitHub is easy. You must be comfortable with Bicep, Yaml, and Git in general. The deployments done in this post are very simple, but with this knowledge, it is possible to deploy any resource using Bicep with Azure DevOps or GitHub. In an upcoming post, I will discuss code organization, Bicep module versioning, and more advanced deployments.
You are welcome to contact me via any of my social media if you have any feedback.