Continuous Integration in Windows Azure
I wanted to do some continuous integration on a .NET project using Virtual Machines in Windows Azure.
The project is hosted in Bitbucket, and I wanted to try out Teamcity to build it.
Firing up a VM, and installing Teamcity was easy. Configuring Teamcity to build the application wasn’t much harder.
Now we get to the interesting bit. My build machine isn’t very busy. It take a few seconds to build my project (it’s not a very big application) and I don’t spend all day and night working on it, so the machine spends most of it’s time being idle. However, being idle is still racking up a bill.
The solution is to start the machine when it’s needed, and shut it down when not.
Bitbucket (like GitHub) supports service hooks. This is the ability to POST to any URL when a commit is made to the repository, so I created a node.js app which will run on Azure Web Sites, and listen to a service hook. It then starts a Virtual Machine, and shuts it down again, 15 minutes after the last request to start it.
The code is available in this gist: https://gist.github.com/richorama/8052843
You can clone the gist, and install it in your own Web Site using Git and the Azure Command Line Tools:
git clone https://richorama@gist.github.com/8052843.git vmstartstop cd vmstartstop azure site create --git [edit server.js to set your own values for subscriptionId, hostedService, deploymentId, roleInstance] [add a mycert.pem file, following these steps: https://coderead.wordpress.com/2013/08/09/managing-azure-iaas-from-node-js/] git add . git commit -am "intial commit" git push azure master
The app supports two actions, start or stop:
https://xxx.azurewebsites.net/start https://xxx.azurewebsites.net/stop
To install in Bitbucket go to Settings, Hooks and add a ‘POST’:
Or in GitHub go to settings, Service Hooks and select WebHook URLs:
Conclusion
When you check in to Bitbucket, the VM starts up, builds the project, emails me if there is a problems, and then gets shut down again. Magic.
Richard Astbury's Blog 
Friday, December 20, 2013 on #WindowsAzure | Alexandre Brisebois 10:33 pm on December 20, 2013 Permalink | Log in to Reply
[…] shared 4 times • coderead.wordpress.com Continuous Integration in Windows Azure | Richard Astbury’s Blog […]
Monday, January 6, 2014 on #WindowsAzure | Alexandre Brisebois 2:18 pm on January 7, 2014 Permalink | Log in to Reply
[…] shared 5 times • coderead.wordpress.com Continuous Integration in Windows Azure | Richard Astbury’s Blog […]
Wednesday, January 8, 2014 on #WindowsAzure | Alexandre Brisebois 12:44 am on January 9, 2014 Permalink | Log in to Reply
[…] shared 18 times • coderead.wordpress.com Continuous Integration in Windows Azure | Richard Astbury’s Blog […]
danmiser 1:52 pm on May 21, 2014 Permalink | Log in to Reply
Thanks for this. I was able to deploy the web site, but it’s not stopping my VM. I don’t see anything coming back in the console. I imagine I didn’t update my variables correctly, but I checked the online reference for startRole from the MSDN site and the only one that seems confusing is the deploymentId variable. I tried both with “prod” (arbitrary) and the Deployment Name listed in the Azure portal for my cloud service linked to my VM. Any thoughts about how best to debug where I went wrong?
Richard 6:00 am on May 25, 2014 Permalink | Log in to Reply
Hi, pleased to hear you’re finding this useful.
The environment should be either Production or Staging.
For debugging I would try using the log steaming service. If you look at the command line tools or the kudu console you should be able to get the log output, and see where it’s going wrong
Thanks.
Richard
danmiser 12:51 pm on May 25, 2014 Permalink | Log in to Reply
Awesome. Thanks for the reply. The log streaming service showed me it was an issue with the cert, so I’ll go back and double check my work there, and I appreciate the environment answer as well.
Thanks again.