When the topic of continuous delivery of builds into the development environment at IP Commerce was initially brought up, we all agreed it was a worthy goal. But from where we were standing at that point the idea sounded very pie-in-the-sky. Then again, so did the idea of building v2 of our product (Commerce Sync) – especially with the aggressive goals and features we wanted to achieve. We needed a better mousetrap.

We are primarily a Microsoft .NET development shop, developing both IIS-hosted and self-hosted Windows services along with supporting MVC (model view controller) websites. We were using the long time standard for source control, Subversion with CruiseControl.net on our build server. The build process may have been automated to the point that it did run our unit tests as a gate for a successful build, and the process reliably produced .msi installation packages for our products, but beyond that it was nearly all manual.

Since the majority of the business logic in our products lives in long-running, self-hosted Windows services, that is where most of the development happens. In the lower development and quality assurance environments, installation of a new service build required grabbing the msi from the build server, remoting into the target server, stopping the service, uninstalling the currently installed version, running the msi and starting the service again. Oh wait, did you forget to copy the old config file before running the uninstaller to diff with the newly laid down config file? It was a mess of potential pitfalls that we were tired of dealing with.

Thankfully for the development team, IP Commerce was going through some changes and we were given the opportunity to aim for that pie in the sky. Around 12 months later we hit it: continuous delivery of software builds into our development environment.

Faster delivery, one click to production

In some ways it is hard to quantify the benefits we have seen from the new process because there are so many. The old headaches have become a piece of nostalgia we now laugh about. It feels like we cut our develop-and-deliver time by 50 percent. And while the hard metrics likely put that particular statistic somewhere south of 50, the feeling is still great. When delivering new features and other changes was slow, we had to choose between quality of output, time to deliver and number of features — we might get two of these, but never all three. Now we don't have to sacrifice any these important elements in a given release. And it’s just one click to get it into production!

The best tool for the job

At IP Commerce, we like to think of ourselves as a “best tool for the job” kind of place. We write .NET code all day long. We love Visual Studio. We think IIS is a perfectly fine web server, and we host our websites and services on Windows machines. After the change, our sales and marketing team commented on how quickly and reliably we were now turning out new product features. That's an interesting barometer for measuring success: When stakeholders who aren't directly involved in a process notice a change for the better, something has certainly gone right.