It’s kind of hard to get you excited about a VitalSite feature that you won’t click, open, save or interact with. And it’s kind of hard to build enthusiasm for something that won’t make your day-to-day work any easier. But I’m going to try anyway. Mostly because it’s important you know about something huge we just released in VitalSite 6.5.
In short, we’ve implemented push button deployments. This means we can now deploy a new version of VitalSite to websites by pushing a button in a deployment dashboard.
The Old Standard Deployment Process
Before we get to why this is important, let’s talk about the standard deployment process. Keep in mind, this process is not specific to VitalSite, or even to Geonetric. It is, rather, what deployment looks like for most hosted products without deployment automation.
Looking over the flow chart, chances are the words “fragile,” “complex,” “unreliable” and perhaps even “broken” come to mind. And for good reason. We all know that any process which appears so complex and incomprehensible is tragically flawed.
In the software industry specifically, a release process that looks like the above imposes all sorts of downstream constraints on the software, not the least of which is infrequent releases. Software vendors end up bundling multiple changes, features and fixes together because it’s difficult to get them to you. We call this bundle a “release,” and the act of getting it onto your sites a “deployment.”
Geonetric averages three to four releases a year, so we’re definitely doing better than most when it comes to delivering new features. Consider, for example, how often a new version of Windows, MS Office, or SharePoint is released. We’re far and ahead better than those products. But compare this to how often new versions come out for other software as a service (SaaS) solutions like Facebook or Google. These get updated frequently and most people don’t even know it. What we do know is that Facebook has about one minor release a day, and one major release a week. Google won’t go on record with specifics, but Matt Cutts admits an update to search at least once a day, and we track on average 500-600 updates a year. For search alone. It’s obvious we have room for improvement.
There are, of course, many more ways that a manual deployment that looks like the flowchart above will constrain the software. The point is not to enumerate all of them. Instead, I’d like to show you how we’ve addressed the problem.
The New Automated Deployment Process
We’ve changed our deployment process so that instead of a dauntingly complicated manual deployment process, it looks like this:
A big green “Deploy!” button for each client, on a dashboard showing all environments.
By automating our deployments, we can now deploy the latest code at the push of a button. Not only does this reduce the time it takes to reliably deploy to all of our client sites, it opens up some opportunities for us in the future:
- Feature Releases: Instead of bundling many changes, fixes and new features into a few deployments a year, we could now push a feature or fix out to you as soon as we finish developing and testing it. Let’s face it, working software that isn’t in your hands is not good for anyone.
- Continuous Deployment: This takes Feature Releases to the next level. We could deploy to production every time a new iteration of the software that passes testing, even multiple times a day. The gap between development and client feedback becomes much shorter, allowing development teams to be more responsive to clients than is possible when changed code takes months to put into use. In addition, the deployment system gets exercised continually, so deployment bugs don’t hide for months before being noticed.
- Improved Quality: Smaller releases with fewer changes typically result in better test coverage and better code quality. Conversely, when you combine many changes together into one enormous release, risk goes up. Feature Releases and Continuous Deployments both mitigate this risk and improve quality.
- Rapid Feature Testing: This is the process where we deploy a new feature, measure how it’s being used, solicit feedback, and improve it. We could do this in a period of days instead of the months it takes when dealing with quarterly releases.
- Self-Service Deployments: With automated deployments, there’s no real need for a developer to be responsible for kicking off a deployment. It’s possible we could turn this over to project managers or even clients directly.
VitalSite 6.5 was the first release to be deployed using our new push button deployment capabilities.
While the release included other enhancements (we’ve included security groups, SEO enhancements, improved public file management, bug fixes, and more) the new push button deployment capability represents a tremendous strategic investment that has the potential to change the fundamental way we develop and deliver VitalSite in the future.
