Create a build pipeline for Angular apps in Azure DevOps

I wanted to show you how I created a Build Pipeline for an Angular App in Azure DevOps.

As always I have this as a task group so I can reuse across projects.

My Task Group for the build is comprised of 5 steps, including tagging the build using PowerShell:

 

 

 

 

 

 

 

 

My Install Node step looks like this, which also add it to the PATH:

 

 

 

 

 

 

 

My NPM install step looks like this:

 

 

 

 

 

 

 

 

My NPM Run Build Script Step looks like this:

 

 

 

 

 

 

 

 

 

This calls the script located in my package.json file as below:

 

 

 

 

 

 

 

I now tag the build using a PowerShell script, this obviously isn’t required but thought I would show it as might be useful for some of you:

 

 

 

 

 

 

 

 

 

 

 

Finally I publish the build artifact:

 

 

 

 

 

 

 

 

 

I hope this shows how easy it is to use Azure DevOps Build Pipelines to build an Angular application with an added bonus of tagging using PowerShell.

You could then have a Release Pipeline use the artifact to deploy to an Azure WebApp or wherever else you wanted.

Hope this was helpful!

Any questions just get in touch via Twitter

Please follow and like us:

Use Git Short Hash in Azure DevOps Release Pipeline

 

I wanted to include the Git Short Hash in the release name of my Azure DevOps Release Pipeline.

I am sure there may be other ways to do this but wanted to show how I did it using PowerShell.

As always I have this as a task group so I can reuse across projects. However, it only has 1 step:

 

 

 

 

The PowerShell within this step looks like this:

$commitId= “$env:BUILD_BUILDNUMBER”

$definitionName= “1.0.0-“

$deploymentId = “$env:RELEASE_DEPLOYMENTID”

$releaseName=$definitionName+$commitId + -$deploymentId

Write-Host (“##vso[release.updatereleasename]$releaseName”)

 

 

 

 

 

 

 

One issue I have found with this is that this obviously only updates once the release has been successfully deployed:

 

 

 

This is because it runs as part of the Release Pipeline. Here is a view of the logs to see it in action:

 

 

 

I figured out the command required to update the release name from these Microsoft Docs at the very bottom under “Release Logging Commands”

Hope you find this post useful and it will help you to build your Infrastructure in Azure using Azure Devops with custom Release Names.

Any questions just get in touch via Twitter

Please follow and like us:

Managing Database Schemas using Azure DevOps

 

A data model changes during development and gets out of sync with the database. You can drop the database and let Entity Framework create a new one that matches the model, but this procedure results in the loss of data. The migrations feature in EF Core provides a way to incrementally update the database schema to keep it in sync with the application’s data model while preserving existing data in the database.

I am using a Task Group for this to keep it as general as possible to allow it ot be used across multiple projects.

My Task Group for the build is comprised of 3 steps, a restore of the solution, the build of the migrations and then a publish of the artifact:

My NuGet Restore step looks like this and also uses the Azure DevOps Artifacts Feed:

My Build EF Core Migrations step looks like this, more info can be found on these scripts here:

ef migrations script -v -i -o $(build.artifactstagingdirectory)\Migrations\$(Build.DefinitionName).sql –startup-project ../$(Build.DefinitionName).API

The final step takes the output of the previous step and publishes it to Azure Pipelines (Artifact Feed):

I use this artifact within a Release Pipeline after I deploy my Web App:

The settings for this look like this:

To give you an idea of the structure, the linked artifacts look like this. This has the app code and the sql script generated in our steps above in seperate folders. (The Deploy Azure App Service step above would just look at the “platform” folder:

 

 

 

 

 

Hope you find this post useful and it will help you to build your Infrastructure in Azure using Azure Devops & Entity Framework Core Migrations.

Any questions just get in touch via Twitter

Please follow and like us:

Using Terraform in Azure DevOps Task Group

I am using Terraform to build my Infrastructure in Azure DevOps using the Task Group feature to keep it generalised. To do this I am using the Terraform Extension from Peter Groenewegen and remote state in Azure Blob Storage.

Thought I would share my setup in the hope that it would be useful for others.

My Task Group is comprised of 2 steps, the Plan & the Apply:

The first part of my Plan setup looks like the below:

 

In the Terraform template path I have used a mixture of built-in system variables and a custom parameter that can be defined in your pipeline

$(System.DefaultWorkingDirectory)/$(RELEASE.PRIMARYARTIFACTSOURCEALIAS)/$(Terraform.Template.Path)

The system parameters can be found here

In the Terraform arguments section I have entered the path to my environment var file. Again I have used the system variable $(Release.EnvironmentName) and ensured that the folder within my Terraform Repo is named exactly the same, along with the tfvars file. This ensures you can keep the Task Group generalised throughout the pipeline.

plan -var-file=”./environments/$(Release.EnvironmentName)/$(Release.EnvironmentName).tfvars”

I have ticked the Install Terraform box to ensure Terraform is installed on the Build Agent.

I have also ticked the Use Azure Service Principal Endpoint Box as per the Terraform best practice guidelines.

The last part of my Plan setup looks like the below:

In this section I declared that I went the state initialised in Blob storage and give the details of where I want this to be stored. Again keeping it generalised by using the system variables.

Within my Terraform code, the Main.tf file has this at the start so it knows to use the remote state:

 

 

 

 

The structure of my Terraform is as below, with the backend.tfvars sitting alongside my $environment.tfvars file. This means you could have completely different settings for each remote state if you wanted. I have it this way as devci1 & qa1 sit in a different subscription to uat1 & prod, so use different blob storage. I also seperate each state into different containers within the blob storage to keep it organised as you will see in the next screenshot.

 

 

 

 

 

 

 

 

The backend.tfvars file looks like the below. The main thing to note is that I change the container name to match the environment (I have changed this to be hard coded for this post but would usually just use the variable to pass the value in to avoid mistakes)

The Terraform Apply section is exactly the same apart from the Terraform arguments section. It has Apply rather than Plan and most importantly the -auto-approve means it doesn’t require any human intervention.

apply -var-file=”./environments/$(Release.EnvironmentName)/$(Release.EnvironmentName).tfvars” -auto-approve 

Hope you find this post useful and it will help you to build your Infrastructure in Azure using Azure Devops & Terraform.

Any questions just get in touch via Twitter

Please follow and like us: