If your application has a frequent release cycles, then continuous deployment should be considered.
The advantage of using a continuous deployment strategy provides version control to roll back to a previous release and the ability to deploy from different branches to different deployment slots in Azure.
Continuous deployments for Azure App Services are available for cloud-based source code management repositories, such as Visual Studio Team Services and GitHub. Once you have set up the desired cloud-based repository, you simply publish your changes to imitate the build and deployment plus any load tests to be carried out.
At time of writing this chapter, the only build application types were only for ASP.Net and ASP.Net Core.
Setting up continuous deployments for these types of applications are made through the Azure portal under your App Service blade as follows:
Clicking the Configure button starts a four-step wizard, the first step allows you to select either Visual Studio Team Services or GitHub as your code repository. Once you have selected which code repository to use, you then select the Project, Repository, and Branch to deploy from.
In the next step, you choose which application type you are deploying, which can either be ASP.Net or ASP.Net core. The last two steps are optional where you can choose to load test the application and choose a staging environment.
Opting in for load testing will spin up 25 virtual users to access your App Service for a duration of 60 seconds.
If you also opted for a staging environment, then the changes will be published to the staging slot first and then promoted to production.
With Azure Functions, continuous deployments are possible using any one of the following supported repositories listed and are configured on a per function app basis:
- Bitbucket (https://bitbucket.org/)
- Dropbox
- Git local repo (https://docs.microsoft.com/en-us/azure/app-service-web/app-service-deploy-local-git)
- Git external repo
- GitHub (https://github.com/)
- Mercurial external repo
- OneDrive: (https://onedrive.live.com/about/en-us/)
- Visual Studio Team Services: (https://www.visualstudio.com/team-services/)
The source code needs to be in a folder structure similar to that of mentioned later with each function in a separate subdirectory from the wwwroot folder and the Host.json file at the root level.
To set up continuous deployment on existing functions, go to the Function app blade in the Azure portal and click on the Function app settings link. Then, under Deploy section, click on Configure continuous integration.
Once the Deployments blade opens, click on the Setup icon to configure the source. Just as we did before, we will configure the source as OneDrive.
Once the configuration has been completed, you should see a new folder created in your OneDrive account under FilesAppsAzure Web Apps as shown here:
Now that the link between OneDrive has been created, we can now download the packages for your functions that you have created in Azure.
Go back to the main Function app blade and under the ageManage section, click on the Go to App Service Settings button. This will then open the Function app blade.
Scroll down and click on the App Service Editor link highlighted in the following image to open the App Service Editor blade:
Once the App Service Editor blade has opened, click on the Go link to open a new browser tab, which shows all your functions.
Hover your mouse over the wwwroot link and click on the ellipse (...) to bring up the context menu. Click on the Download Workspace link to download the wwwroot.zip file, as follows:
Now unzip the file and copy the whole contents to the function folder that was created in your OneDrive.
From the Deployments blade, you can synch deployments with your OneDrive folder contents and previous deployments.
If using cloud-based source code repositories such as Visual Studio Team Services or GitHub, any modifications to your source files are copied to the function app and a full deployment is triggered.
Note
When using Visual Studio Team Services as your deployment repository source and you cannot see your projects, it may be due to your VSTS account not being linked to your Azure subscription. See this link for the steps to set it up: https://github.com/projectkudu/kudu/wiki/Setting-up-a-VSTS-account-so-it-can-deploy-to-a-Web-App.
PowerShell scripting is a great tool to automate the managed deployment for Azure resources. In this section, we will walk through the step-by-step process to create a PowerShell script, which can be used to deploy the Logic App definition and parameter JSON file into specific subscription and resource group. You can extend the PowerShell script as per your requirement.
There are certain prerequisites that need to be installed properly before you can get started with PowerShell Script and ARM template. The prerequisites are listed here:
- Install Microsoft Azure SDK for Azure
- Install Azure PowerShell and set
executionpolicytounsigned
We will divide the PowerShell script into different sections and add appropriate synopsis to explain them in detail. Let's now go in detail to develop the Script from start.
This PowerShell script uses modules such as AzureRM, Resources and Azure.Storage .We have defined a parameter, which will differ from environment to environment, such as subscription, resource group, and resource location. If you have not gone through the concept of earlier-mentioned parameters, we would suggest to go through Chapter 2, What Is an Azure App Service? for the detailed explanation.
After listing the necessary parameter for the PowerShell script, we start with defining appropriate functions to do the specific task such as register the resource group under a specific Azure subscription.
Next two functions perform actions to check the existence of resource group within the specified Azure subscription and to deploy the Azure resources such as Logic Apps, as follows:
We have one more last function defined within the PowerShell script to give a user option to select the environment that will be used within the runtime:
After you have successfully written the necessary function (in this PowerShell Script, we have four functions), you can use those functions definition within the script as follows:
