Continuous Deployment for Lazy People

Some people claim that paradoxically laziness is the power of civilization, because if people weren’t lazy, there wouldn’t be so many inventions. Is it really a true statement? Maybe laziness isn’t the source of development, maybe it’s eternal human desire to conquer and subordinate the rest of the world? Maybe laziness it’s only a reward, a side effect of this action? However it’s better to leave that considerations. Let’s think about something concrete! In our world, such subordination could be called automatization. And it’s worth to think about it in our work.

This short text have a special task: to show how fast, minimalist and efficient we can realize the process of Continuous Development by using Vistual Studio Online and Azure. It can be very good base for future development of CD. Let’s start!

VSO, Azure + Continuous Deployment

In brief, it works like that: when Git pull request is created, the code is automatically issued on Azure Website at URL, which contains a name of the branch. We are able to start, see how it looks and test the application… After closing a pull request, everything is cleaned up and deleted. Voila! It’s fast, minimalist and efficient. Now let’s see, how, where and when it’s happening.

But hey, what we exactly want to achieve? Let’s say our workflow looks like that

1. Programmer receives a Work Item, e.g. “Task nr 4 – users management”
2. We create a new branch called e.g. 4-users, because we are working with feature branching approach and programmer starts implementation.
3. Implementation ends and programmer marks pull request to merge 4-users branch to master branch.
4. After reporting pull request, web application is deployed as Azure Website at the URL f.e. projectname-4-users.azurewebsites.net
5. Pull request is under code review by another programmer and it’s marked as Approved.
6. QA team tests application under previously mentioned URL and marks pull request as Rejected.
7. Programmer fixes bugs, commits changes and pushes.
8. Application is once again automatically deployed.
9. QA section tests application and marks pull request as Approved.
10. Pull request is being merged to master branch.
11. Application under URL projectname-4users.azurewebsites.net and everything connected to it (e.g. database) is being deleted.

Magic

Let’s focus on two points regarding automagic application issuing and deleting. We need Azure subscription, and the first step would be connecting VSO with Azure.
In chosen project, click settings (icon in the top right corner).

Then, choose “New Service Endpoint” and after that “Azure Classic”.

Choose authentication by using certificate. If you want to download file with certificate and the rest of data to fill, you should click “publish settings file”.

Let’s create application build called “PublishToAzure”. In build tab, click plus sign, then choose Visual Studio. After that, we need to indicate, where are the sources of our project and we are able to see steps of our build.

1. Delete all steps except “build solution”.
2. In “msbuild arguments” in “build solution” step, add /v:q /m
   • /v:q – it’s shortcut from /verbosity:quiet, it minimalizes infomation, which msbuild prints. It can shorten build time.
   • /m – if it’s possible, msbuild wil compile our project using few cores
3. Add next step “AzurePowershell” and add below code as a script:

Naming websites using template {project_name}-{branch_name} has a great advantage – during manual management using manage.windowsazure.com, websites are sorted by projects.

Next step – creating build, which will delete application from Azure. Let’s call it RemoveFromAzure. In this build, we care about only about “AzurePowershel” step. Two lines are important:

Finally, the last step is to create small web application. VSO has a Web Hook mechanism, which can send POST to URL given by us. In this way, we can integrate VSO with our company’s Slack team, but we will use it in a different way.
Scheme of our workflow:

1. Programmer creates pull request
2. Web Hook notifies our application
3. Our application, depending on pull request status (updated, closed or abandoned):
   • triggers PublishToAzure build
   • triggers RemoveFromAzure build

Summary

Pros of that solution:

1. new features are ready to test ASAP
2. no time-wasting on manually deploying application’s version to QA section
3. when developer finishes assigned task, application is being deleted

Cons of that solution:

1. websites are being created on free plan, which has limited resources, e.g. RAM
2. it’s possible to add another step to build (“AzureResourceManager”) and to change plan to e.g “Basic”, but you must be aware, that’s connected with another costs.

Above text it’s only our solution, how you can approach to Continuous Deployment in the simplest way. Remember, that’s not important HOW you will realize it, it’s important, that you will try to implement that in your work and to adapt it to your needs. In that way, we can have more time for coding, which we like the most.