A fellow member of the Sydney .NET developer community and all-round Internet guy, Doug Rathbone, has recently launched the beta of his Cloud-powered deployment system, OnCheckin.com.

As I’m a firm believer in Continuous Delivery as a means to deliver better, more relevant software, more often, I am always interested in new options entering the fast growing market of tooling to help implement automated deployments. So, this Sunday morning I sat down and took a look at Doug’s solution.

OnCheckin.com currently offers several different pricing plans starting from free and increasing with additional feature sets and the number of sites you will deploy. As part of being a hosted solution, OnCheckin is currently focused on automating the deployment of websites. Specifically it currently works with .NET web applications, version controlled in a Git, Subversion or TFS source repository hosted with a multitude of providers like GitHub or CodePlex or even with your own on-premises repositories if they are reachable from by the OnCheckin servers. As a deployment target OnCheckin currently supports FTP (secure and otherwise) and Microsoft Web Deploy, technologies that any .NET developer should be familiar with. The OnCheckin model makes it obviously suitable for public-facing websites but I can’t see any reason why it couldn’t also be used to deploy private sites if the deployment endpoints is secured appropriately.

Curious to see just how easy OnCheckin could be to use, I created a new ASP.NET MVC4  web project, committed it to a new Git repository and pushed it to my existing GitHub account. I then went to WindowsAzure.com and signed up for a free trial and added an Azure Website to my subscription. With my source and target ready, I signed up for the free OnCheckin plan, specified the relevant GitHub, Azure, and web project details and I had an automated deployment solution ready to run in less than 30 minutes since I started.

I could have then clicked the Run link to deploy immediately but the service is called “OnCheckin” so I decided instead to make a small change to my web app code, commit it, and push it to GitHub. By time I had switched back to the browser tab with my OnCheckin deployment management page open the service had detected my check-in and started to get the source and build the solution.

Unfortunately the first build failed because I hadn’t correctly specified the folder that the solution was in or the name of my web project to deploy. So I went back to the OnCheck  project settings page, fixed the values, and this time clicked Run to trigger the deployment. While waiting for the deployment to complete I checked my new website and found that the Azure placeholder had disappeared and been replaced by a friendly OnCheckin offline page which was a nice touch. After about 7 minutes from clicking Run, my website was running and browsable from its URL on Azure. Very slick.

I did notice a few areas for improving the user experience of OnCheckin.com and I’ve provided a list back to Doug who has been very open to accepting feedback. I have an upcoming personal website project in the next few weeks and I’ll definitely be looking at OnCheckin.com to handle the deployments.