What does it look like to deploy a DevOps project into Azure for a Java Application?

Introduction

A few months ago “Azure Devops Projects” was released. As I haven’t had the time yet to test-drive it, I was still sceptic towards the service from a naming perspective. In full disclosure, for me DevOps is about three aspects ; People, Processes & Products (“Tools”). The last part is typically, and maybe surprisingly, the most easy part to do. That being said, as I tried this service, I must admit that this service reduces the friction to set up an end-to-end project. This is where the Azure Devops Project shines! It guides you in a step-by-step manner to set up the end-to-end project for a variety of languages and deployment methods.

 

A brief walk-through

As we all know, the proof of the pudding is in the eating. So let’s see what the flow looks like in reality?

 

Once we go to the “DevOps Project”, we are prompted to select what language will power our new application ;

Here I selected “Java”, and now I’m prompted to select a framework (Spring or JSF) that will be used as a base ;

Once you have selected the framework, you can choose what type of deployment method you want; Web App for Containers (Linux & Container based) or the Web App (Windows-based) ;

In this case, I’ve selected the containers/linux variant. Next up, I can create a new or existing Visual Studio Team Services (VSTS) account, and choose a project name. In the same pane, I can also choose the linked Azure subscription / resource group / app service ;

Now let’s press done and we’re off!

And you can see the deployment kicking in…

And a bit later we’ll see some emails arriving ;

Stating that all went fine, and we’ll even get an email saying that the release went succesful!

 

Point-of-View : VSTS

First of all, let’s take a look at our VSTS account. We can see that the code repository was initialized with a sample project.

And we can see that a build definition was added. This one is being triggered upon every code change (Continuous Integration, CI) ;

As we chose the container variant, we see that the build definition was setup to include to build & push an image towards a repository (which will be created for you).

And the same for a release definition ;

Which is triggered by the build definition (Continuous Deployment, CD) ;

And there is already one deployment task in there that will push the container (and settings) into the App Service ;

Point-of-View : Azure

First thing to notice, is that a service endpoint was created… This is the link towards your Azure subscription and also indicates which “Service Principal” will be used to manage (deploy, etc) things.

When looking into our Azure subscription, we’ll see that a new resource group was added and that it contains various resources ;

When taking a look at the App Service, we can see what URL is being used for our deployment ;

And we can see that our (initialized dummy) project is live!

 

Doing an update!

As an additional test, let’s change the code of the web page ;

Changing some text and adding a nice meme. Afterwards committing the code…

Once committed, we’ll see that the build will kick in.

Triggering maven inside of the container build ;

And afterwards being released to our App Service.

Now everyone can enjoy our Nyan cat meme… 😉 And of course, we get an email stating that the build/release went fine!

Closing Thoughts

The Azure DevOps project is, to me, a great way to initialize / kickstart your projects. Is it the tool that will setup every scenario for you? No. Though it will setup a found basis where I’ve seen a share of customer struggle. By using it, you can get on your feet quickly and adapt/extend the project with your own specific tweaks and relieving you from the initial grunt work.