Deploying to Azure -Part 8

8 min readApr 14, 2019

Well this is the last article of the series where we create and deploy an API using Azure functions.

In here we’ll deploy the API which we created to Azure using Azure Devops pipelines.

Continuous Integration and Continuous Deployment (CI/CD)

The moment of truth of any application which we develop, is the time where we need to deploy the application. It can be to either to a testing, staging or even to a production environment.

As we know by experience unless you have a CI/CD process the deployments are not always so pretty and highly unpredictable. Most of the time this is what really happens,

The developer builds the solution and creates a package (zip file) with all the configs — Person A
This package is given to a person who has all the security clearance to the environment which the deployment needs to be done — Person B
Now Person B, logins to the server, follow a written guideline (or a step by step article) and perform those actions manually.
Either Person B comes unscathed from the other end, or both person A and person B go back and forth with their heads on fire about what went wrong, is it the code? or did I miss something in the steps to deploy! 😆 yeah it’s bloody chaotic!

But nowadays we have many tools which can be used to make this process seamless and easily duplicated.

One such tool is Azure DevOps and at least in my opinion it’s your best friend especially if you are deploying to Azure.

If you don’t have an account please create one. Use this link and click the big button “Start for free” to create one.

Create a project

All the build and release pipelines are maintained inside a project. It’s like a small management portal where you can manage all the tasks, code and of course the build and release pipelines (yes you can and, actually should have multiple build and release pipelines per environment depending on the situations)

Associate the code with the project

Now we need to associate our code with the project. Remember that our code is currently in GitHub. But if you want to maintain the code inside Azure Devops you can do that too.

Click on the “Repos” button and, then you see what are the options which you have,

But since our code is already in GitHub, we’ll import it to here. Click on the “Import” button and follow the steps to import it.

Once imported you will see the code under “Repos” section in your project.

Now we have the “code” which we can apply CI/CD. So prior to the deployment to Azure, we need to check whether the code builds and, whether the tests are executed successfully. What can we gain by doing this?

By creating a CI process, the team can have a guarantee whether the code builds and the tests are passing successfully in the environment which they are planning to deploy.
The developers can commit code to their hearts desire and, that burden of whether “well this works in my machine, but not in this server” syndrome will be gone.
If the build is failed then it’ll be notified to the developers and, most of the time they just need to check the latest commit and investigate.
Focus more on the important stuff, such as building features and being awesome by writing cool and beautiful code (yeah lots of it! :creepy! )

Create a continuous integration process — A.K.A build pipeline

Click “Builds” in the “Pipelines” section in your project and create a new pipeline.

Choose “GitHub” and authenticate yourself. Then select the repository and the branch which you would like to create the build pipeline for.

Choosing the repository and the branch in GitHub

Now we need to select a template where Azure DevOps already have the predefined steps to create a build pipeline. Since our application is a solution created using .NET Core, the most matching template is “ASP.NET Core”. So go and select it.

Choosing a template for the build process

Alter the pipeline

We’ll modify only a couple of things in here, the name of the pipeline and un-check the option “Publish Web Projects” in the “Publish” task.

Changing some defaults in the build pipeline

Enable continuous integration

We want to perform these tasks (Checkout code, restore, build, run tests and publish) every time a commit is made to the branch. So we need to enable continuous integration.

Save and queue the build

Let’s do a build and check whether we can have a successful build.

This will queue a build aaaand… we have a successful build!

Perform a build using the build pipeline

Great, now we have a build process which will make sure the code is built, the tests are executed properly and the artifacts are created which will be used for the deployment. Most importantly this will be done for each commit which we make to the branch.

If you want to check the “continuous integration”, check-in some code to the branch and then browse the “builds” section to see a new build is in progress.

Creating a “Release” pipeline

Now it’s time to deploy the application. We’ll take the artifacts which was created in the build process and use them to deploy in Azure.

Create a release pipeline

Select a release pipeline template. Select “Azure App Service deployment”.

Customize the release process

Change the name and click on the “1 job, 1 task” link.

Do the modifications as shown below (select your subscription from the “Azure Subscription” drop down model)

Select the artifact from the build pipeline

If you can remember we wanted to migrate the database as a part of deployment too. So we need to do this in here and, this is the approach we need to take,

Extract the database migration artifact. You can see that artifact in here,

Since this is a console application we can call it using a “command line task” in the release pipeline.
The console application needs the connection string to be passed.
The connection string need to be obtained securely from AKV by defining a pipeline variable.

Let’s customize it now.

First we need to extract the artifact. For this we can use the “Extract Files” task and, once you add it move it as the first task and modify the values as shown below,

Select the folder to extract and the destination folder.

Set the artifact file location (pattern) in the “Archive file patterns” and add a “destination folder” name.

2. Create a variable to store the connection string retrieved from AKV. In Azure DevOps all the variables belong to a certain variable group. For this let’s create a new variable group as shown below,

Then link the AKV and the required key name with the variable as shown below,

Link the subscription and select the key vault

Adding a variable pointing to the secret key in the AKV

3. Link the variable group with the pipeline

Link the variable group with the release pipeline

4. Add a “Command line” task and call the console application passing the variable you created in the previous step.

Make sure that the tasks are in the same order as shown above.

Now we have a release pipeline which we can used to deploy our API to Azure.

Let’s create a release manually and test whether this works!

Click “Release -> Create Release”

Select the build which you want to deploy and click “Create”

Then a release will be queued and the deployment will progress

Once it’s done you can see that it was a success and now you have the API built and deployed in Azure!

Go to the Azure portal and browse to your function app. Use it’s public url to access your API

Enable continuous deployment

Go to the release pipeline and click on the thunderbolt icon in the artifacts section and enable continuous deployment as shown below,

There you go. We created an API using Azure functions along with some other related technologies and patterns. Finally we deployed it to Azure using Azure DevOps pipelines.

Thank you for reading this series of articles. Please feel free to add any kind of feedback so that I can improve.

Thanks!