Product and service reviews are conducted independently by our editorial team, but we sometimes make money when you click on links. Learn more.

Integrate Azure Functions into your DevOps SDLC

By - Source: Toms IT Pro

Azure Functions serverless approach promises to help with caring for DevOps infrastructure.

Companies need to be more agile, get things out the door more frequently and more reliably. But let's face it, most traditional deployments take way too long and are usually very prone to errors, with deployment processes taking up 500 manual steps in someone's Microsoft Project file.

By taking a lot of unnecessary things off our shoulders, like the need to care for infrastructure, Azure Functions, with its "Functions as a service" (or some call it serverless) approach promises to enable companies to be just that.

MORE: Microsoft Azure vs. AWD: Cloud Platforms Compared

In the last articles, we talked about the different ways of deploying Azure Functions, be it via the command line (CLI), Visual Studio or from git, we also talked about how testing and debugging of Azure Functions works on your local development machine through Visual Studio and the CLI.

Blue – green deployments

Something that has been already a thing for a long time are "Blue – Green deployments". You might call them "A/B" or "testing in production".

If you have not heard of this, then imagine this. You are currently running version 1 in production and are working on version 2 of your stack. The way very mature teams test this version 2 is by deploying it right into production, next to version 1, as a new stack, run their (automated) tests against it and if the tests pass they flick a switch (point DNS names) from version 1 to version 2 and destroy version 1.

On Azure this feature is called "Deployment slots" and has already been available on Web Apps for quite a while. Other providers might call this feature "stage" on their Gateways.

Blue/Green Azure Functions

Browsing to your Function App in the Azure Portal you will see the "Slots (preview)" button. Click on the "+" button and you will be asked to enable Deployment Slots in your Function App's settings.

This is a one-way street. You cannot disable this feature after enabling it. However, having it enabled, but not using it, will not interrupt any functionality.

Turn the feature on and return to the now empty "Slots" tab. Click the "+" icon to create your first slot. We will create a "staging" slot in this case. This way our goal is to always first deploy to "staging" and only if we are satisfied promote / swap our code from this "staging" slot to production.

NOTE: As of May 30, 2017, there is no update to the PowerShell cmdlets or CLI yet, so we need to use the Portal for all of this. Also, note that consumption based plans only allow to have one deployment slot.

Our Function App is now reachable on the following URLs:

- (staging slot)
- (production slot)

From here we can now click the new "Swap" button on our Function App to start the swap process.

You need to provide this process with three parameters.

  1. Swap type ("Swap" or "Swap with preview")
  2. Source slot
  3. Destination slot

"Swap with preview" copies your code and all configuration across to the other slot, let's you test everything and waits for your confirmation that everything is fine. Only then will it complete the swap.

It is important to know that swapping slots not only means the actual code, but also the configuration, this includes Function App settings, connection strings and secrets.

Deployment slots can and should be targets of Continuous Deployment setups (see previous articles), so that you can target a slot with your test code and then promote to the next slot.

With this your code and process has arrived at a very high maturity level. You can start testing in production.