Implementing continuous integration and continuous delivery with Azure Functions

Now that we have created a simple application through the Azure portal, the next question is how do we add a multiple number of functions, source code them and set up automated build and deployment. We do this, of course, through DevOps and automation. Let's start with continuous integration. As we know, continuous integration is an integral part of DevOps, where an application is integrated to work as one unit. We have to achieve the continuous integration, automated testing and continuous deployment for Azure Functions through automation. 

To start, we will first create an assembly line. The assembly line starts with a code repository like GitHub or SVN and concludes with production deployment. Everything within this has to be automated with almost minimal manual intervention through a pipeline. We will be covering pipelines in detail in the next chapter.

To achieve continuous integration, we need to start with pushing the code into the GitHub repository. The developer should start building the application by creating a featured branch for building each piece of a functions module, then all the featured branches should be reviewed and merged to develop branch and finally to master branch for clean code building. All the featured branches should go through a continuous integration process , that is, a functions code will go through unit testing , state code analysis and various other testing in an automated way. Then code from the featured branch should be merged into the master. The master branch is used to build and deploy to a UAT or OAT environment, where performance testing should be performed and further deployed into production.

The continuous delivery process kicks in at the moment the developer checks in code into the local or featured branch. The automated build will be triggered, which is followed by unit testing and integration testing. Even though the code is very well tested, it still needs to be tested for usability and acceptance testing. So, a successful exit from the continuous integration process will trigger a continuous delivery process and delivery to QA staging. The QA environment normally resembles a production environment. This is where automated and manual acceptance testing kicks in. Having continuous delivery in place, we should be able to release the environment daily, weekly or fortnightly, or whatever suits the business requirement. But we should be able to deploy to production without much effort or manual deployment. 

Let's look at an example which follows the continuous integration and delivery. In this example, we will be using open source DevOps tools to actually test and deploy the application on the Azure Cloud. We need tools like Jenkins, which is a popular open source orchestration tool, and the serverless framework which we used for AWS deployment, and the Node.js module for unit testing the code.

For my feasibility, I have used Docker for setting up the Jenkins instance with Node.js and npm installed on it. I have pushed the Dockerfile for this on the Git repository where all the example files reside on the GitHub link below, and also my tutorials are built on Linux: https://github.com/shzshi/azure-helloworld-ci.git

If you are using the Dockerfile from the Git repository, then make sure Docker is installed on your laptop/PC. We will first clone the previous mentioned Git repository and build the Docker image with jenkins, serverless framework, and all the required dependencies for Azure Functions deployment, with the following command:

$ git clone https://github.com/shzshi/azure-helloworld-ci.git
$ cd azure-helloworld-ci
$ docker build -t chapter4jenkins:latest .

Then run the Docker container with the following command, this will create a container with Jenkins, Node.js 8.9, Serverless Framework 2.5 and npm 5.6:

$ docker run --rm -d -p 50000:50000 -p 8080:8080 chapter4jenkins:latest
If you already have Jenkins set up, then make sure you have Node.js 8.9, npm 5.6, and serverless framework 2.5 installed on the server for the previous example to work. 

Once Jenkins is up and running, we will create a job in Jenkins which will run the unit test and then deploy the Azure Function through a serverless framework to the Azure Cloud. Once successfully deployed, we will invoke the function through a serverless framework.

Use the following steps in order:

  1. The following is the screenshot of the Jenkins homepage. We will create a new job, so click on the link New Item and create a new job:

  1. Create a job name, whatever suits, and select Freestyle project and submit OK:
  1. Then we will redirect to the configure page for the job, where we will add the Git repository for cloning, click on the Source Code Management tab, and add details in the Git repository as shown here: 

  1. Then click the Build tab and create an execute shell, and, through the Add build step drop-down menu, we add npm install to install the required Node.js modules from the internet, and then run the Node.js test, which will unit test the Azure library function and give us the result.

We can add many unit tests to test our function, before deploying it to Azure Cloud, to make sure the app is unit tested before it goes on to the cloud:

Make sure you have the Publish HTML report plugin already installed through steps Jenkins Home | Manage Jenkins | Manage Plugins

  1. Once we run the preceding job, then a unit test is performed and the report is generated for the unit test, which we can view by configuring post-build action. So, let's click on the Post-build Actions tab, then click on the dropdown Add post-build action and select Publish HTML reports, click on Add and then configure it as per the following screenshot: 
  1. Save the job and run the build. Once the job has built successfully, we should be able to view the code coverage HTML view, from the job's homepage. The coverage will look like the following screenshot, which should give us a good view of how our unit test has performed:

In the previous section, we unit tested our function and looked at coverage of the function. Next we will configure deployment onto the cloud.