In January I presented at the Sydney ALT.NET user group about HTTPS, focusing on all the new advancements in this space and some long-held misconceptions too. It was well received so I re-presented it at the Port80 Sydney meetup in March.
I met Steve Cassidy from Macquarie University who was also presenting at the same Port80 meetup and I was invited to present the talk a third time as a guest lecture to second year Macquarie University Computer Science students on May 4th. The lecture was filmed but is only available to those with a student login. My slide deck from Port80 is available on SlideShare though.
This year my friend Aaron lead the organising of the return of the DDD conference in Sydney. I submitted a talk proposal and was fortunate to receive enough votes to earn a speaking slot. So, on Saturday May 28th I presented “Web Performance Lessons” which covered a variety of scenarios I had encountered while improving the performance of other people’s websites as part of my job at section.io. The talk was recorded by the conference sponsor SSW and is available to watch here. Also my slides can be viewed at SlideShare.
At the Port80 meetup in March I also met Mo Badran who organises the Operational Intelligence Sydney meetup. Mo asked if I could do a presentation of how section.io handles operations so on Tuesday May 31st I presented “Monitoring at section.io” where I shared a bunch of detail about our tools and processes for operational visibility at section.io, both for the platform itself, and for users of our CDN. Those slides are published on SlideShare too.
I’ll take a break from speaking in June and instead absorb what other people have to share at the Velocity conference in Santa Clara and take the opportunity to also check out the new section.io office in Colorado.
I know this blog has been quiet for a while. I have been posting most of my written content over at the section.io blog lately and will probably continue to blog there more often than here in the near future. Some of my recent posts include:
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.
In general, an automated build server should be usable to build multiple projects and multiple revisions of a single project. An automated build server should also be disposable, it should not contain any special configuration that isn’t already tracked in source control, and provisioning a new build server should not require hunting for the installers for specific versions of dependencies.
By default however, the Windows Azure SDK for .NET doesn’t work this way. To build an Azure project from a build server you need the full SDK installed and suddenly this means the build server is tied to only building projects targeting a specific version of the Azure SDK. If several projects share a single build server then all projects need to be upgraded to the new SDK when one project is upgraded and performing builds on maintenance branches becomes difficult if not impossible.
Simply copying some Azure SDK files into a source-controlled “Dependencies” folder won’t help much either because the (v1.6) build scripts make some assumptions:
- The Azure tools are located at a fixed path under the Program Files folder
- The Azure SDK is located at a path referred to by a HKEY_LOCAL_MACHINE Registry key
- A common .targets file has been installed in the MSBuild extensions folder so every project system-wide references it automatically
Finding and fixing these assumptions is required so that a source-controlled copy of the SDK will work but these assumptions can change (and have changed) in each new version of the SDK so it is important not to be tempted to edit the original files but instead utilise the various hook points in MSBuild to override these assumptions.
Ideally the Azure SDK would just be a Nuget package but until the product team can be convinced to do this, I have published some scripts which allow you to build your own Nuget package of the Azure SDK with all the afore mentioned assumptions fixed. My scripts require a machine with the SDK already installed because I doubt I have the rights to redistribute original files.
The scripts are available in a Mercurial repository hosted on Bitbucket. After cloning or downloading a copy of the repository, just run MSBuild in the root and it will gather the necessary SDK files from your system and produce a Nuget package in the “output” subfolder. From there you might ideally install the package in your Azure project (the *.ccproj file) using this command from the Package Manager Console:
Install-Package -Id Microsoft.WindowsAzure -Source [path to the "output" subfolder]
Unfortunately, at the time of writing this Nuget (also v1.6) doesn’t support Azure projects so slightly more work is required. First, install the package into the target solution’s “packages” folder using the “nuget.exe” command-line interface:
nuget.exe install Microsoft.WindowsAzure -Source [path to the "output" subfolder] -OutputDirectory [path to the solution "packages" folder]
The open the Azure project’s “.ccproj” file for editing in a text editor and add the following line immediately after the opening <Project … > element:
<Import Project="..\packages\Microsoft.WindowsAzure.1.6\tools\Microsoft.WindowsAzure.Nuget.targets" />
Note that the relative path to the “.Nuget.targets” file may be slightly different depending upon project and solution directory structures. You can vote to get Azure support added to Nuget here.