Microsoft’s Azure App Service is worth a look.
Whether you’re a developer or an operations engineer, Azure App Service enables you to develop and deploy applications more quickly. And since it’s a fully managed platform, teams can focus more on their applications without getting bogged down by all of the intricacies required to build and maintain scalable and highly available infrastructure.
For example, small development teams without an operations staff can use Azure App Service to accelerate application deployment, since there’s no need to stand up servers, networking and storage resources. For organizations with dedicated operations staff, Azure App Service reduces the need for time-consuming administrative tasks, such as backups and patching, since Microsoft fully manages those.
In addition, teams can now use Azure App Service with Visual Studio Team Services (VSTS) to enable continuous delivery. VSTS is another Microsoft cloud-based service for teams to collaborate on projects and includes services for version control, continuous integration, release management and more.
Continuous delivery workflow in Azure App Service
The idea behind a continuous delivery pipeline is to allow teams to more confidently deploy application changes. It’s not a vendor-specific concept, nor does it rely on a particular set of tools. Instead, continuous delivery is a process that ensures teams validate and test frequent changes to the code base before they consider those changes production-ready. VSTS is just one product teams can use to create a continuous delivery pipeline, but it offers some powerful capabilities and has a setup process that makes it easy for new users.
A continuous delivery pipeline built for an Azure App Service web app can include the following stages:
- Develop application code: In this stage, one or more developers actively work on the code base for an application. The application code is stored in a version control repository. When a team makes small, incremental changes to the code base, those changes are committed and pushed into the version control repository.
- Build: Any changes to the application that are stored in the version control repository automatically trigger a build process to compile code and optionally run unit tests. Since developers commit small, incremental changes into the code base, they can quickly catch any issues with this model. These first two stages are essentially the basis for continuous integration. Fast feedback about the success or failure of new features enables developers to iterate quickly on the application.
- Test: In the next stage, teams can execute optional load tests to ensure the most recent version of the application is production-ready. To do this, deploy the latest version of the code into an Azure App Service web app that is built specifically for load testing.
- Deployment: Finally, once you complete all the stages in the continuous delivery pipeline, deploy the latest version of the application. Teams can choose to deploy into the production environment or into a staging slot. In either case, this is the end of the pipeline, as the source code is considered production-ready. If the automated deployment pushes the code to a staging slot, teams can swap the staging slot with the production slot when they’re ready to go live with the new version of the application.
Set up a continuous delivery pipeline for a web app
To test this process, I’ll use a basic ASP.NET MVC web application that was built in Visual Studio 2015 using the default project template. I’ve also set up two web apps in Azure App Service: one for my production application and one for load testing.
To get started, go to your production web app in the Azure portal. Select Continuous Delivery (Preview) under the Deployment section, as shown in Figure 1.
Click on Configure.
Next, you’ll see each stage of the continuous delivery pipeline that needs to be configured, as shown in Figure 2.
Click on the first item labeled Choose repository. This enables you to define your version control repository. Valid options currently include VSTS Git, GitHub or an external or local Git repository. In my case, I’ve stored my sample application in GitHub.
When you select GitHub as your source, you are prompted for your GitHub credentials. Once authenticated, select your source code repository, along with the appropriate branch. In my case, I’m committing my code changes directly to the master branch, as shown in Figure 3.
Now that I’ve defined the source stage, I can set up the build stage. In this case, I’ll select the appropriate application framework, which is ASP.NET. I’ve also elected to create a new VSTS account, as shown in Figure 4.
If you already have a VSTS account, you can select the Use existing option. Also, select a region that makes sense for you based on your location.
Next, I have the option to set up a load test, as shown in Figure 5. This isn’t required, but for the sake of demonstration, I’ll enable this stage in the pipeline using another web app I created solely for load testing.
Finally, configure the deployment stage, as shown in Figure 6. By default, the option to deploy to a staging environment is set to No. This means that code changes will automatically deploy into the production web app, once all the other stages are completed successfully.
If you prefer to deploy to staging first, simply select Yes on the Deploy screen as shown in Figure 6. This enables you to select either a new or existing staging slot you have configured for this web app. After you set up your deployment options, click Ok, and Azure builds out the continuous delivery pipeline in VSTS. This initial configuration triggers the execution of the pipeline, and you’ll be able to review the build and release stages in the VSTS console.
From this point forward, code committed to the source repository triggers the build, test and deploy stages in the pipeline again. The new version of the application is available in the staging slot of the web app. Finally, you can swap the deployable version of the application in the staging slot with the production slot whenever the team is ready to roll out the changes to the rest of the world.
Keep in mind that the continuous delivery feature in Azure App Service is still in preview, and the process outlined above could change before it’s considered generally available.