Continuous Delivery of Azure WebJobs via Git

Continous delivery (or continuous deployment or continuous integration) is an important part of the modern software development lifecycle.
Azure WebJobs on the other hand is a nice little feature to run processes in the background.

This article describes in short why continuous delivery is a good thing, what Azure WebJobs are and how you can use both together.

What is Continous Delivery?

Wikipedia describes Continuous Delivery as follows:

Continuous Delivery (CD) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be
reliably released at any time.

The basic idea is to integrate a new feature or bug fix as fast as possible in a highly automated fashion. Normally you use different stages the code has to go through before it gets into production. Short hint: Slots are the way to go in Azure Web Apps (this is out of scope of this article).

What are Azure WebJobs?

WebJobs are part of the Azure Web Apps service and allows an application to run background work on demand, on a schedule or triggered by an event. This can be helpful when you want to move data from a database to Azure Table Storage via one click or process new data as soon as it is written to an Azure Storage Queue.

Create an Azure WebJob

Let’s start with creating an Azure Web App in the Azure portal.


Click on Web Apps in the navigation bar on the left hand side. You should now see all your Web Apps. If you don’t have one you should see something similar to the following one.


Click on Add at the top, give your Web App service a name, choose a subscription, choose an existing Resource Group or create a new one, choose an App Service plan or create a new one and click on Create at the bottom.


After the creation is finished you should see the dashboard of the Web App you just created.


Alright, that should be enough for the beginning. Let’s start coding. Our Node.js application is maybe the simplest one you have ever seen.

console.log("the simplest Node.js application someone has ever written");

Manual deployment

Back in the portal, look out for the WebJobs section. If you click on it you should see that there’s is no WebJob yet.


Let’s upload our JavaScript file. Give the job a meaningful name, set it to run on demand and choose our JavaScript file we created earlier.


After the file is uploaded you should see the job.


Before we get to the next step let us examine how our Web App looks like in the console. This will be important at a later point.


As you see our job is under App_Data\jobs\triggered\Hello World. Now it’s time to trigger our job. Currently there’s no way to do it in the Ibizia portal, so we have to go back to the old portal. Find our Web App, choose the WebJob and click on Run Once.


After the run is completed we can go to SCM. If everything went good we should see a successful run on the dashboard.


Click on the run and you should see the output of the console. The most important line is the INFO line which shows our log message.


Create a Git repository

Ok, let’s get this thing automated. Before we start: Do you remember the folder structure we have seen in the console in the Ibiza portal? To get everything right, let’s create this structure on our local drive – App_Data\jobs\triggered\Hello World. The next thing we need is a Git repository. Run the following commands in the root folder (the one which contains the App_Data folder).

$ git init
$ git status
$ git add .
$ git commit -m "Initial commit"

With that we intialize a new Git repository. The git status command let’s you see what the best next step could be, for example adding a file to the tracking of Git. The last step is to commit our changes.

Connect the Azure Web App to Git

Before we can deploy our app automatically we have to connect our new Git repository with Azure. Under Continuous deployment choose Local Git Repository as the source.


Next we have to set up the credentials for deploying from the command line.


$ git remote add azure
$ git push azure master

Let’s see how it looks like in the portal. Go back to Continuous deployment and you’ll see a new deployment.


If you like you can see the details of the commit.


Automatic deployment

Alright, let’s do the great finish. First we make a little change to our log message.

console.log("the simplest Node.js application someone has ever written with Azure WebJobs");

To get the changes pushed to Azure we first need to commit our changes and then push it out to Azure.

$ git commit -am "Changed message"
$ git push azure master

Back in the portal you’ll see a new commit.


As the last time, you can have a look at the details of the commit.


Start the WebJob again in the old portal and switch back to SCM for the last time to verify our new message is logged.



In this article we have gone through the basics of continuous delivery and Azure WebJobs. We created a simple Node.js application and uploaded it manually. Next we have created a Git repository and connected it to Azure and started the automatic deployment with a different message to log.

Jan (@Horizon_Net)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s