Update:
Click here for the SoCalCode camp presentation about this topic.
Introduction
This post would
introduce you to continuous delivery pipeline using Azure app services. We
would take a use case and implement the steps that we need to take in order to
establish a build pipeline.
What is Continuous Delivery?
In simple words “Constantly develop, automatically build and
automatically deploy”. This means that as soon as code is checked in a system
would automatically build the application and deploy.
Azure App Services
Azure app services is a set of technologies that enable
development of cloud centric Web Apps, Mobile Apps, API Apps and Logic Apps. There
is a great introduction to App Services presented at: https://azure.microsoft.com/en-us/documentation/articles/app-service-value-prop-what-is/
.
Power of App Services
To understand the power of Azure App Service you have to
compare to a classic Web Application with any of the technology such as Azure
App Service Web App. In a classic Web App, a web server such as IIS is the main
component. The Web App is installed on IIS and the pages are served through IIS
to internet audience. This is a typical on premises infrastructure
implementation. You are responsible for managing the security, availability,
scale and instrumentation. Part of the classic web app infrastructure is the responsibility
of not only delivering the web app but maintenance of the web server. This
includes the separation of environments such as development site, QA site, UAT
site and the production site. Also, since web server maintenance is part of
this infrastructure, you have to also think about the actual server where that
web server is installed. The environment that server offers greatly effects how
the web server would work. This is another layer of responsibility that a web
developer has to keep in mind.
With the App Services, the IIS part has been abstracted
away. This means that management of web server (for example IIS) is not the
focus but the focus is the delivery of web app. As an application developer we
can easily create on App and have it hosted in different deployment slots.
These deployment slots makes it easy to create environments such as development
site, QA site, UAT site and production site for the same web app.
Continuous delivery pipeline for Azure App Service
Since web server and the server hosting the web server is
not part of Azure App Service, the establishment of continuous delivery
pipeline is very easy to establish.
Our focus for this post is to list the steps and design
patterns that we can use to establish the continuous delivery pipeline.
There are three major steps to establishment of continuous
delivery pipeline for Azure App service. These are:
Establishment of development slots
Once you have created an Azure Web App, you have to define
its deployment slots. Usually the deployment slots are representation of your
different environments. For example, in a typical web development effort you
would have following environments:
1.
Development:
This is the environment that is used by development team to help them develop
different aspects of the project. Typically this is referred simply as “dev”.
2.
QA:
This environment is used by the QA team to test the web app separate from the
development environment. This is great for providing isolation and also to do
better validation testing. Typically this is simply referred as “qa”.
3.
UAT:
This environment is used by product owners or stake holders to validate
different features after the QA has signed off. Again an isolation from dev and
QA allows the UAT to test the web app irrespective of the test data that QA has
used to valid. Typically this is simply referred as “uat”. Usually a separate
database is attached for the UAT environment.
4.
Staging:
This sometimes also known as pre-production. Typically is used to validate the
build process and once the build is validated, this environment is swapped with
production. Usually the staging environment uses the same production database.
This allows the swapping from staging to production seamless without any down
time. Typically this is simply referred as “staging”.
5.
Production:
This is the actual web application that represents the production environment.
Typically this is simply referred as “prod”.
The Azure App Service gives each deployment slot a unique
URL. This essentially means that each of the deployment slot is a separate web
application. Each of the web app URL representation of the environment is used
by different team members. Development team members use the dev URL, QA uses
the QA URL, and UAT uses the UAT URL for the web app.
Here is an example of different deployment slots for our API
web app.
Establishment of branching strategy
There are a lot of different branching strategies that are
used in the industry. The branching strategy is designed or sometimes evolved
based on respective objectives. One of those objectives is the environment.
What it means is that for different environments different braches are
established. To simplify let us take the following branching strategy.
Master branch – For Development environment
QA Branch – For QA and UAT environments
Production – For staging environment
Importance of branching strategy means for continuous delivery
Since the main tenant of continuous delivery system is to
automatically we build and automatically from a code check in, we have to pay
extra attention to where the code check in takes place. If we look at our
branching strategy, it would mean that if we check in the code in the master
branch then dev environment should be build. If we check in the QA branch then
it means that QA and UAT environments would be build. Same goes for the staging
environment. This is why your branching strategy should be representative of
your build environments. Let us take a typical scenario to explain more:
Joe (Backend developer) completes first part of the story
and checks in the code to master branch. This kicks off a fresh “dev” build.
Jessica (Front end developer) completes the second part of
the story and checks in the code. This kicks off another fresh “dev” build.
Since the second part of the story completes the story. The build manager
merges the master branch into QA branch. This kicks off a QA build and a UAT
build for both QA and UAT team members.
Establishment of build/publish process
Azure App Service deployment
There are multiple ways to deployment apps on Azure App
Service. There are:
FTP
This is a most direct and classical way of deploying any web
app. The major drawback is that this a total manual process. If you need to
automate this, you have to write quite complex scripts.
Web Deploy
This tool allows you to directly deploy web apps to azure
app service from visual studio. Although you do not have to use FTP for this
scenario but you still have to do actual deployment manually.
Kudu
This build engine is used where we want to have automatic
build/publish execution when a source code repository is attached. This means
that as soon as a check in take place on a branch (established in step 2), the
kudu build process would kick in a do the rest.
Code checked-in to repository >> Kudu initiates the
build >> Kudu publishes the website
Multiple web apps challenge
The above mentioned steps would work great if you have only
one web app in your code repository. For example, you have create a dedicated
branch for one web app that has one solution file (.sln). The challenge comes
in the shape of a scenario where you have multiple web apps and they all share
the same code repository. For example, in a typical business application, you
might have one web app that serves the pages and one Web Api app that is
consumed by the web app. You might have different release pipeline for WebApi
and web App. In this scenario the visual studio solution would contain both
projects as part of the solution.
To accommodate the scenario of multiple web apps projects in
a solution, you have to take some extra steps.
Step 1. Add app setting to your App Service to uniquely
identify your app. This is to give Kudu a way to kick start the build and
complete the publishing once code has checked in.
Step 2. Add “.deployment” file to the base of your source
code repository. The “.deployment” file gives Kudu a starting point to start
the deployment process. Here is a sample:
As you can see what the “.deployment” file is asking Kudu to
do is just to call deploy.cmd file. We would look at this in next step.
NOTE:
NOTE:
Before proceeding further it is important to note that following are prerequisites for the next steps:
1. Nodejs: https://nodejs.org/en/
1. Nodejs: https://nodejs.org/en/
2. azure-cli: https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-command-line-tools/
Step 3. Create deploy.cmd file. This is the file that would
tell Kudu how many different web apps or web Api apps are available in your
code base that needs to be built as part of continuous integration pipeline.
Here is an example of deploy.cmd file:
If you look at this file, you would notice that there are
three web apps that are mentioned in the code. These are the three projects
that are part of same solution file. What this code is doing is checking which
App Service has kicked started the build process. This essentially means the
branch where the code check in has happened. The SITE_FLAVOR comes very handy
here as we use this App setting to identify the application.
After the app service identification, the deploy.cmd is just
calling the corresponding individual deployment files. In our examples there we
have three different deployment files. Those are:
deploy.customersapi.cmd
deploy.customersweb.cmd
deploy.anotherapi.cmd
In our next step we would see how you create these
individual deployment files.
Generating Deploy.customer.cmd
Step 1:
Assuming that your customerapi’s project file is
at c:\sites\CustomerApi\src\CustomerApi.csproj and customerapi’s solution file
is at c:\sites\CustomerApi\src\CustomerApi.csproj and c:\sites\CustomerApi\CustomerApplication.sln.
Execute the following command using elevated Administrator mode either on
command prompt or Powershell prompt. I always prefer PowerShell because of ease
use.
azure site deploymentscript --aspWAP c:\sites\CustomerApi\src\CustomerApi.csproj -s c:\sites\CustomerApi\CustomerApplication.sln
Step 2:
Running the above command would yield a file called deploy.cmd. Rename file deploy.cmd to deploy.customersapi.cmd.Step 3:
Repeat steps 1 and 2 for customersweb and anotherapi projects.Conclusion
Azure App services are set of very powerful technologies that gives a very clear pathway to establish a continuous delivery pipeline.
SocalCode Camp presentation
The following presentation about this topic presented at the 2016 SocalCode camp.
