Forem: Dan Wright

Deploying static webs apps with the Azure cli and bicep

Dan Wright — Tue, 04 Jun 2024 22:49:08 +0000

Deploying static web apps

A brief intro deploying Azure static web apps using the Azure cli, and Bicep, Microsoft’s domain specific language (DSL) for deploying Azure resources.

This will deploy a create-react-app (CRA) starter repo located in a DevOps repo using a simple .yaml file into a static app resource.

Azure cli deployment

As a precursor to deploying via the cmd line you will need the azure cli installed

Use az version to determine if you have the cli installed. If not follow these instructions for installing https://learn.microsoft.com/en-us/cli/azure/install-azure-cli

Login using az login and set the subscription you wish to work in with az account set --subscription <SUBSCRIPTION-NAME>.

Create a resource group to manage any resource deployed using az group create –name <RESOURCE-NAME> –location <LOCATION>

Finally deploy the resource into the resource group at a location az staticwebapp create – name <SWA-RESOURCE-NAME> –resource-group <RESOURCE-NAME> –location <LOCATION>

In the Azure portal under resource groups navigate to the newly deployed resource group which will contain the static web app.

Bicep

This will deploy 1 resource and 1 module into a resource group within a subscription. Create a new git repo in Azure Devops to work in which will can be deployed using a ./azure-pipelines.yaml file.

In order to create the resource group set the scope of the ./main.bicep file from its default of resourceGroup to subscription and then deploy the resource. The parameters needed will be passed in from a ./mian.parameters.bicepparam file that can be altered.

./main.bicep

targetScope = 'subscription'

// Parameters imported from `./mian.parameters.bicepparam` file
param globalTags object
param resourceGroupName string
param resourceGroupLocation string
@description('Timestamp last deployment')
param utcShort string = utcNow('d')

var customTags = {
  LastDeployed: utcShort
}

resource resourceGroup 'Microsoft.Resources/resourceGroups@2024-03-01' = {
  name: resourceGroupName
  location: resourceGroupLocation
  tags: union(globalTags, customTags)
}

The parameters file will hold customizable options needed to deploy the resources. Update the resource group name and location with values and add custom global tags to be used in all resources.

./main.parameters.bicepparam

using './main.bicep'

param globalTags = {
  Environment: 'Dev'
}

param resourceGroupLocation = '<RESOURCE-GROUP-LOCATION>'
param resourceGroupName = '<RESOURCE-GROUP-NAME>'

To add the staticWebApp and keep its config out of the main file and aid reuse add the staticWebApp as a module.

./modules/static-web-app.bicep

@description('Global tags')
param tags object
@allowed(['centralus', 'eastus', 'eastus2', 'westus', 'westus2'])
param resourceGroupLocation string
@description('Timestamp last deployment')
param utcShort string = utcNow('d')

var customTags = {
  LastDeployed: utcShort
}

resource staticwebapp 'Microsoft.Web/staticSites@2023-12-01' = {
  name: 'azStaticWebApp'
  location: resourceGroupLocation
  tags: union(tags, customTags)
  properties: {}
  sku: {
    name: 'Free'
  }
}

From here you can deploy the resources using the Azure cli, using az deployment sub create --location centralus --template-file ./main.bicep --parameters './main.parameters.bicepparam'

To deploy the resources through a pipeline create a './azure-pipelines.yaml' file and use an inlineScript to run the same cli command as above.

'./azure-parameters.yaml'

trigger:
- main

name: Bicep deploy

variables:
  vmImageName: 'ubuntu-latest'
  AzureServiceConnection: <SERVICE-CONNECTION-NAME>
  bicepParamFile: './main.parameters.bicepparam'

pool:
  vmImage: $(vmImageName)

steps:
- task: AzureCLI@2
  inputs:
    azureSubscription: $(AzureServiceConnection)
    scriptType: bash
    scriptLocation: inlineScript
    useGlobalConfig: false
    inlineScript: az deployment sub create --location <LOCATION> --template-file ./main.bicep --parameters $(bicepParamFile)

In Azure DevOps create a service connection that can be used to grant access to Azure for deploying resources into:

DevOps -> project settings -> service connections
New service conection -> Azure Resource Manager -> workload identity federeation (automatic)
Scope: subscription -> ResourceGroup: leave blank -> Add a service connection name and description -> Grant access permission to all pipelines

Once created replace <SERVICE-CONNECTION-NAME> with the name of the newly created service connection and push the code changes.

Deploy create react app

Create a new repo with create react app and add a './azure-pipelines.yaml' file that deploys the repo in the static web app any time new changes are pushed to it.

'./azure-parameters.yaml'

trigger:
  - main

pool:
  vmImage: ubuntu-latest

steps:
  - checkout: self
    submodules: true
  - task: AzureStaticWebApp@0
    inputs:
      app_location: '/'
      output_location: '/build'
    env:
      azure_static_web_apps_api_token: $(deployment_token)

Get the deployment token from the static app resource under the Manage deployment token at the top of the overview tab.

Inside Azure DevOps click create a new pipeline from an Azure GitRepo with an existing Azure pipelines yaml file. On the review stage add new variable for the deployment_token and add the static web app deployment token before running.

Validate the web app has been deployed by navigating to the URL on the overview tab.

Now any time now changes are pushed to the create-react-repo those changes will be deployed to the web app.

Link to the Git repo

Developing Azure functions using reusable Bicep modules

Dan Wright — Mon, 24 Apr 2023 13:32:22 +0000

The benefits of infrastructure as code

Infrastructure as code (IaC) is the practice of a creating a model in code to generate an identical environment each time it is run, reducing human error, enforcing business best practice, and allowing teams that use it to innovate and deploy needed infrastructure faster and safer than manually generating the resources when needed. IaC is a fundamental concept utilizing DevOps methodologies to automate the validation, build and deployment of infrastructure in a way that closes the gap between development teams and IT operations teams.
Using IaC we can ensure that environments created are appreciative of cost, using environment config, reusable, using modules, and require minimal human input, using CI/CD or cmd line deployment. With this approach we can be confident that teams wishing to use our templates can do so in a business approved way giving them confidence to take innovation into the cloud or rapidly deploy new infrastructure to an existing environment.

Azure Resource Manager (ARM) templates

ARM templates are JSON files that define the deployment resources and variables. They can be used to create azure resources in a declarative modular way that provides built in validation and the ability to preview changes. The template contains a schema to determine the version and language, properties, variables, function, resources, and outputs.

{
  "$schema": "https://schema.management.azure.com/schemas/...
  "contentVersion": "",
  "apiProfile": "",
  "parameters": {  },
  "variables": {  },
  "functions": [  ],
  "resources": [  ],
  "outputs": {  }
}

When using the Azure portal to create a resource these templates can be found at the ‘Review + Create’ stage under the ‘Download a template for automation’ link at the bottom.

Bicep

Bicep is Microsoft’s domain-specific language (DSL) used to deploy Azure resources in a declarative modular way. Additionally, like ARM templates they can be used with what-if operations to preview the impact the deployment will have. Unlike ARM templates Bicep syntax is less verbose and defines simpler syntax for writing parameters and conditional operators among others and introduces annotations including @describe and @secure.

Azure CLI (Command Line Interface)

The Azure CLI is the simplest way to work with ARM or Bicep files and most notably can be used to:
Decompile a Bicep file or files from an ARM templates -
az bicep decompile –file {ARM_TEMPLATE_NAME.json}
Build an ARM template from a Bicep file -
az bicep build –file {BICEP_FILE_NAME.bicep}
Deploy bicep to a resource group -
az deployment group create –name {RESOURCE_GROUP_NAME} –file {BICEP_FILE_NAME.bicep}

Azure Functions

Azure functions provide a platform for developers to build and deploy application logic in a way that does not require them to maintain the underlying infrastructure required to run them. Azure functions build on the principles of serverless computing by providing on-demand compute allowing consumers to meet changing demand whilst paying only for what they use.

Azure Functions is a Function as a service (FaaS) and to be deployed will require:

storage account - Used to store app data, potentially app code, and will be used to manage operations including triggers and logging function executions.
hosting plan - Used to define resources available and how the function is scaled.
function definition - Used to define the function runtime amongst other app config

Creating a functions resource file

In order to run the bicep file a resource group needs to be created. To do this via the cmd line:

az group create --name rgfunappdev001 --location eastus

The resource group name should follow best practice naming:

rg-<app or service name>-<subscription purpose>-<###>

Creating a storage account:

@description('Storage account')
resource azStorageAccount 'Microsoft.Storage/storageAccounts@2022-09-01' = {
  name:  'azapp${uniqueString(resourceGroup().id)}'
  location: resourceGroup().location
  kind: 'StorageV2'
  sku: {
    name: 'Standard_LRS'
  }
  properties: {
    supportsHttpsTrafficOnly: true
    minimumTlsVersion: 'TLS1_2'
  }
}

Creating a hosting plan:

@description('App service plan')
resource azHostingPlan 'Microsoft.Web/serverfarms@2022-03-01' = {
  name: 'host${uniqueString(resourceGroup().id)}'
  location: resourceGroup().location
  sku: {
    name: 'Y1'
    tier: 'Dynamic'
  }
}

Creating a function:

@description('Function app')
resource azFunctionApp 'Microsoft.Web/sites@2022-03-01' = {
  name: 'azfun${uniqueString(resourceGroup().id)}'
  location: resourceGroup().location
  kind: 'functionapp'
  identity: {
    type: 'SystemAssigned'
  }
  properties: {
    httpsOnly: true
    publicNetworkAccess: 'Enabled'
    serverFarmId: azHostingPlan.id
    siteConfig: {
      appSettings: [
        {
          name: 'AzureWebJobsStorage'
          value: 'DefaultEndpointsProtocol=https;AccountName=${storageAccountName};EndpointSuffix=${environment().suffixes.storage};AccountKey=${azStorageAccount.listKeys().keys[0].value}'
        }
        {
          name: 'WEBSITE_CONTENTAZUREFILECONNECTIONSTRING'
          value: 'DefaultEndpointsProtocol=https;AccountName=${storageAccountName};EndpointSuffix=${environment().suffixes.storage};AccountKey=${azStorageAccount.listKeys().keys[0].value}'
        }
        {
          name: 'WEBSITE_CONTENTSHARE'
          value: toLower(functionAppName)
        }
        {
          name: 'FUNCTIONS_EXTENSION_VERSION'
          value: '~4'
        }
        {
          name: 'FUNCTIONS_WORKER_RUNTIME'
          value: 'node'
        }
        {
          name: 'WEBSITE_NODE_DEFAULT_VERSION'
          value: '~18'
        }
      ]
      cors: {
        allowedOrigins: ['*']
      }
      ftpsState: 'FtpsOnly'
      minTlsVersion: '1.2'
      netFrameworkVersion: 'v6.0'
      use32BitWorkerProcess: true
    }
    clientAffinityEnabled: false
    virtualNetworkSubnetId: null
  }
}

Using bicep files with config hard-coded into the resources means that the file will only ever deploy that instance of the resource. Having the resource only able to do 1 specific task reduces its reusability, and, increases the need for alterations based on differing need, introducing the potential for error and not adhering to company best practice and cost. If the user wishes to deploy more than this single file, they will need to make multiple deployments, causing them to ensure they correctly deploy resources dependent on others to reduce the risk of deployment failures.

Externalizing config

The aim of decoupling the config from the resource allows the resource to be reused for differing deployment variations based on user requirements. Doing so means that config and infrastructure policy can be maintained and controlled independently of the resource creator.

External JSON files can be loaded into the ./main.bicep file and then passed into the resource.

@description('Function App config')
var environmentConfigurationMap = loadJsonContent('./environmentConfigurationMap.json')

environmentConfigMap.json

{
    "production": {},
    "test": {},
    "dev": {
        "azFunctionApp": {
            "identity": {
                "type": "SystemAssigned"
            },
            "kind": "functionapp",
            "node": {
                "workerRuntime": "node",
                "version": "~18"
            },
            "properties": {
                "clientAffinityEnabled": false,
                "httpsOnly": true,
                "publicNetworkAccess": "Enabled",
                "siteConfig": {
                    "cors": {
                        "allowedOrigins": [
                            "*"
                        ]
                    },
                    "ftpsState": "FtpsOnly",
                    "minTlsVersion": "1.2",
                    "netFrameworkVersion": "v6.0",
                    "use32BitWorkerProcess": true
                }
            }
        },
        "azHostingPlan": {
            "kind": "windows",
            "sku": {
                "name": "Y1",
                "tier": "Dynamic"
            }
        },
        "azStorageAccount": {
            "kind": "StorageV2",
            "properties": {
                "supportsHttpsTrafficOnly" : true,
                "minimumTlsVersion": "TLS1_2"
            },
            "sku": {
                "name": "Standard_LRS"
            }
        }
    }
}

To ensure that the correct environment config is used the '–parameters' flag can be passed into the cmd line instruction and used within the main.bicep file as a param.

`az deployment sub create --location 'centralus' --parameters 
 environmentType=dev --template-file ./main.bicep`

@description('env config types')
@allowed([
  'production'
  'test'
  'dev'
])
param environmentType string

The @allowed annotation will cause the bicep build to throw an error if a parameter is provided that is not allowed, it also notifies the user of the intended expected options. A user could easily use this template to provision a dev, test or production environment but could not use it if they wanted a UAT environment.

Reusable resources

To make the function app resource defined in the ./main.bicep file reusable it can be externalized into its own file, './funcationApp.bicep'.
This file will no longer have direct access to the config which it needs to define the resources but rather have them passed into the file as params that can have their type and name defined at the top of the file.

Using the storage account (azStorageAccount) defined previously, it and its params will look like:

@description('Storage account sku')
param azStorageAccountSkuName string
@description('Storage account kind')
param azStorageAccountKind string
@description('Storage account support Https only')
param azStorageAccountSupportsHttpsOnly bool
@description('Storage account minimum Tls Version')
param azStorageAccountMinimumTlsVersion string

@description('Storage account')
resource azStorageAccount 'Microsoft.Storage/storageAccounts@2022-09-01' = {
  name:  'azapp${uniqueString(resourceGroup().id)}'
  location: location
  kind: azStorageAccountKind
  sku: {
    name: azStorageAccountSkuName
  }
  properties: {
    supportsHttpsTrafficOnly: azStorageAccountSupportsHttpsOnly
    minimumTlsVersion: azStorageAccountMinimumTlsVersion
  }
}

This process can be then done for each of additional resources that are defined to complete the function app.

Modules

Once the config has been externalized and there is a way to select the relevant environment config options, update the ./main.bicep file to include a module which encapsulates the resource to be deployed. This means that our main.bicep file will be easier to read and offer a way to template the deployment of our resources.

Using the azStorageAccount the module will look like:

module funcAppModule './funcationApp.bicep' = {
name: 'funcApp'
  params: {
    location: resourceGroupLocation
    azStorageAccountKind: storageAccountConfig.kind
    azStorageAccountSupportsHttpsOnly: storageAccountConfig.properties.supportsHttpsTrafficOnly
    azStorageAccountMinimumTlsVersion: storageAccountConfig.properties.minimumTlsVersion
    azStorageAccountSkuName: storageAccountConfig.sku.name
    ...azHostingPlanParams
    ...azFunctionAppParams 
  }
  scope: resourceGroup(resourceGroupName)
  dependsOn: []
}

Conclusion

Once completed the config used to define the values for the properties of the resources to be deployed will be contained in a .json file that can be managed and maintained by DevOps teams who understand the business best practices around deployments, costs, and naming conventions. The function app resource will now be in a separate file containing all the properties needed to create the resource but will be decoupled from any deployment config values, allowing it to be reused for any given number of deployments. The ./main.bicep file used for deploying the resource will define the parameters needed to be passed in via the cmd line and will be responsible for providing the resource with the correct config. Using this approach, dev teams can have a faster reproducible, approach to deploying needed resources that can be business approved and deployed via an automated pipeline.

Source code:
https://github.com/sirBassetDeHound/bicep_function_app

Focus on the principles and not the methodology when in an agile environment - (or just be more lean)

Dan Wright — Thu, 24 May 2018 13:19:17 +0000

I have been working in an Agile environment for about 4 years, it’s my first time working in that environment and I have come to realise that we can often become too preoccupied with the methodology and adhering to that methodology that we can forget what we were trying to solve by becoming agile.

I have for the first time given a 10-minute lightning talk on this topic and thought that I would put it down in an article.

The intention is to try and help those attempting to embrace agile, to navigate through the jargon but also remind those already working in an agile environment to take a step back and refer any changes or discussions to the agile principles, or better yet, lean principles.

Recently I have been trying to introduce someone in a non-agile non-technical environment that agile will help them better manage their day to day. It has been a very worthwhile exercise for myself to better understand agile without the emphasis on software development. To do this I fell back on the 'explain it to me like I am a 5-year-old' approach, which made me think about what agile is to me, and I came up with:

'It encourages me to remain customer focused whilst delivering a continuously increasing quality of work with less waste'

Whilst this may seem a simplified view of agile I think it explains the reason for adopting agile quite well, on a level non-agile, non-technical people can easily get on board with.

Before the methodology came the principles

Lean really took hold in the 1930 - 1950's from the Toyota car manufacturing plant in an effort to become competitive in the industry. By looking at processes in the delivery system they realised small incremental changes could provide better less wasteful delivery. It was here where the concept of looking at flow through the system was defined, and the 5 principles of lean were developed.
A full history of lean can be found at: https://www.lean.org/WhatsLean/History.cfm

Lean and Agile have always had a connection, the initial Agile developers had all looked towards lean for inspiration. Martin Fowler explains that Mary and Tom Poppendieck helped inspire the original agile way of thinking and its principles. Mary, working in a manufacturing plant and Tom working in software. Both being active members in the agile community shaping its direction in the 1970 - 1990's.
For the full article by Martin fowler on this: https://martinfowler.com/bliki/AgileVersusLean.html

The agile manifesto was created with 12 principles in 2001 which encourage a way of working that adapts the lean principles for software development. It is the agile manifesto that is credited as being the defacto guide to agile working supported by the 12 principles.
The agile manifesto and the 12 principles: https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/

Once the principles were in place different ways to adhere to those principles formed starting with Crystal in the early 1990's and has since gone through many changes and is adapted in many different ways, some of the more popular include, Scrum, Kanban and SAFe.

The principles

Lean kit (https://leankit.com/learn/lean/lean-principles/) defines the 7 principles of agile as:

Lean Principles
Optimize the whole	Create knowledge
Eliminate waste	Defer commitment
Build in quality	Respect people
Deliver fast	--

These 5 principles, as shown at the lean.org (https://www.lean.org/WhatsLean/Principles.cfm) form the lean continuous learning loop:

I find these 5 principles or stages of the loop when used with the 7 lean kit principles helpful to cement the lean thinking that is needed to be 'working lean'. Identifying the value to the customer gives the constant reminder of remembering who you are providing the service for before mapping the way to achieve what the customer desires. Once understood remove all obstacles from the flow of that service ensuring that it gets to the customer in a timely waste less manner of a high quality. Establishing pull in the system drives you to validate the need for the product, ensuring that work is not done that is not needed and then meeting that demand in the timeliest way possible without creating inventory. The Kanban Methodology encourages this pull of flow through the system rather than a push of the flow, this workflow builds responsible / respectful delivery of work to the next stage in the process, rather than just 'throwing it over the fence'.

The 12 agile principles as defined by the agile manifesto (https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/) build upon the previous lean thinking adapting it for software development.

Agile Principles
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software	Working software is the primary measure of progress.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.	Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.	Continuous attention to technical excellence and good design enhances agility.
Business people and developers must work together daily throughout the project.	Simplicity--the art of maximizing the amount of work not done--is essential.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.	The best architectures, requirements, and designs emerge from self-organizing teams.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.	At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

They promote, individuals and interactions over process and tools, working software over comprehensive documentation, customer collaboration over contract negotiation and responding to change over following a plan. To me this sounds a lot like its roots, Lean. The 12 principles in my opinion, whilst I do not disagree with the message that they are trying to deliver could be reduced.

Without tackling all the principles, there are a few I wish to call out. Working software as the primary measure of progress, this principle can cause team members to become too focused with just getting 'tickets' completed and does not have any place for hypothesising, experimentation and learning. How does 'fail fast' and 'proof of concept' fall into the working software that I am to be measured by? Building projects around motivated individuals, prioritising face-to-face communication and continuous attention to detail, are 3 more principles that I consider to be good working practice of a mature software employee and possibly more a pre-requisite of a modern working environment that we should just naturally be doing.

One agile principle that I think stands above all others is that, ‘the best architectures, requirements, and designs emerge from self-organising teams’. I believe this is a really important principle and one that I feel advances the lean principles, as teams we should be responsible for our own workload, prioritisation and how to achieve the goals set forth by the customer. This should be something individual teams dictate, after all it is the team that will be held accountable for tasks not being completed.

To give some weight to my thoughts the agile principles are already being shrunk down, with 'modern agile' or 'heart of agile'.

Modern Agile: http://modernagile.org/
Heart of Agile: http://heartofagile.com/

The problems with Methodologies

When you have chosen to become more agile or are working in an agile way you will likely be working with an established methodology. But how do you know it’s the right one? I honestly believe that no methodology is perfect and this can often be an issue. Trying to adhere more to the scrum principles is not the same as being more agile, adhering to a methodology can often feel like you are going against the agile principle of being a self-regulating team.

Methodology’s should be treated as guidelines and not things to hold people accountable for not doing the 'task' in the right way. Treating any methodology as a guideline allows for blended (agile + agile), or hybrid (agile + good idea) ways of work, ensuring teams remain flexible to their working environment and self-regulating. Working in a Kanban way but want to promote more pair programming (Extreme programming), not a problem if the methodology is a guide and not a hard and fast rule.

Integration with the business or customer can be challenging if they do not know about agile and they are receiving emails, or involved in conversations about sprints, velocity, backlogs and t-shirt sizes. This lack of understanding can develop a lack of trust or confidence in those doing the work, which can turn into a lack of funding. Not talking methodologies to people and explaining without Jargon the agile reason for doing something can help build relationships, and can lead to non-agile people integrating with agile practitioners better. When we remove the focus from why we do agile to how we are doing agile we are adding a layer of abstraction between ourselves and the reasons for practising agile, we forget the motivation for doing agile and focus on the way to accomplish a task, which may not be in a very agile way.

So why focus on the principles?

Agile methodologies are a tool, like a JavaScript library or an IDE, and should be used as such. With this thinking we can see that all agile tools have the same tool kit, the '5 whys', Continuous feedback loops, customer focus, Transparency, to name a few. Focusing on the idea of why we do agile, customer focus, better deliverables, reducing waste, faster delivery, we can pick the best tool for the job, and not be limited to what a methodology says.

We can be truly agile by embracing the freedom agile gives us to do our job.

Whilst I know this has not been a deep dive into agile, its methodologies and the tools we use to do its job I hope that it helps remind people that we should take a step back from what we are doing and ask ourselves 'is this decision agile'?