Azure Functions are Microsoft’s solution for the execution of code in a “serverless” environment – that is, where you worry about the code, and leave the Azure Functions service to worry about the hosting infrastructure.
There are three hosting plans for Azure Functions – Consumption, Premium and Dedicated. However, no matter which hosting plan approach makes sense for your needs, there is an option to use deployment slots, provided the Azure Functions service is being run at an appropriate pricing tier.
In an ideal world, testing would be perfect, and every deployment to the production environment would proceed flawlessly. Of course, in reality this is not the case, and sometimes a deployment to the production environment uncovers a coding issue that needs to be rolled back.
The use of deployment slots with Azure Functions means that a rollback process is simple to achieve. By deploying code releases to a non-production slot (at Walkerscott, we use a slot called “deploy”), and then swapping the “deploy” and production slots when it’s time for the code to go live means that the previous production code from before the deploy will be in the “deploy” slot after the swap.
If things go wrong, then the “deploy” slot and production can simply be swapped again, to get back to where you were before the deployment started. This is one reason that Walkerscott always recommends using slots in production environments.
Of course, rolling back to the previous version is not without potential problems either. When you have a range of improvements being deployed – some of which may be business critical to go live ASAP – and a limited window in which to deploy these updates, having to roll everything back to the previous release just because of a critical issue in one function is hardly desirable.
Fortunately, understanding that Azure Functions slots operate as independent environments provides a solution in this kind of scenario. In the case where a deployment does have an issue with one (or more) functions, but a complete rollback is not considered desirable, it is possible to update the system to use the functions in the “deploy” slot (being the previous known good version of the code) where required, while the remainder of the system operates using the new code just deployed in the production slot.
Where Azure Functions are called from Logic Apps, for example, functions may be being triggered via a URL of the form:
To revert just this function, it’s a simple matter to update the Logic App to use the code from another slot:
This approach allows a deployment with a fault in one function to avoid a potentially costly complete rollback, by only rolling back to the previous code version for the faulty function.