Editor’s Foreword: When Donte Ormsby came to us, it was just a friendly letter to say that he found a great tool for simplifying website deployment using ASP.NET and thought our readers might find it useful. After talking a bit, we decided the best way to introduce DubDubDeploy to you would be for him to just tell his story.
If you know of a product that has really helped you and are willing to share your experiences, by all means let us know. We interested in both formal case studies and casual user stories. Jonathan Allen, Lead Editor, .NET Queue
Our story begins in late 2010 in the software development department of a local financial institution. As a software engineer on this team, I was responsible for not only writing the code for our various applications, but also managing the application servers and deploying our websites. Our environment was pretty immature, making it difficult to keep track of all of our apps in source control, as well as the various servers to deploy to.
We had quite a few web applications in our world, from intranet applications to public-facing websites to customer portals. And of course each application had multiple environments and servers - generally one or two each in production, QA, and development - sometimes more, sometimes less. Application deployment was a major issue for us - in addition to the sheer number of locations, we also had infrastructure issues to deal with.
Every developer had 9 Windows logins - 4 different domain accounts (spanning 3 domains), and 5 individual machine accounts for servers not on a domain. So deploying to a server meant using one account to connect to the build server, and a different one to connect to the target server. Permanently mapping drives was not an option just because there were way too many to deal with - several dozen application locations, many of which were not obvious based on their server names and directory names.
Not everyone wanted to learn all of the dozens of different application locations, so it fell on a select few of us. It was a fast-paced agile shop, so code was constantly being checked in, deployed out to different environments, and even to production pretty often. Several times per day I'd have to stop what I was doing to deploy an application - which meant trying to remember where the app lived, logging in to the UNC shares or mapping new drives, manually backing up the files, and manually pushing out the new code. I found out that when I was out of the office, people were afraid to deploy things, or didn't remember their passwords, or didn't know where they were supposed to copy things from or to - so things just didn't get done.
Between the lost productivity caused by constant interruptions, the delays in getting code deployed to test, and dealing with human error when code was accidentally deployed to the wrong places, we were wasting several hours every week, which easily turns into hundreds of valuable developer hours wasted every year.
After recognizing the problem, my first attempt at a solution was to put together a few batch files which attempted to automatically map drives on demand for your given application and environment. But this still meant that you had to remember your 9 passwords, and that your user account was still good (which for some reason wasn't always the case). This helped a little, but we really needed a more permanent solution, one that everyone felt comfortable using.
Then we found DubDubDeploy, which was pre-release at the time. The product promised to deploy files across a network over HTTP instead of the file system, which meant all of our problems with network access and user security would no longer be applicable. So we decided to give it a try. If we could even get back a tiny percentage of the wasted time and effort, the license fee would pay for itself in a matter of weeks.
The product required a small installation on the build server, as well as each of the target web servers. Configuration was straightforward - we just needed to define where the application was allowed to copy files to, and which Windows users were allowed to run it. After it was set up, backup and deployment went from a painful multi-step process to literally a single click.
Also included with the product was a Nant script generator and CruiseControl.NET project config generator. We were already using these two products, but the samples provided gave us some ideas on how to improve our scripts. Having a solid build process is a must for any serious project, and I always welcome all the help I can get improving my build strategy.
Counting each application and environment, our team dealt with about 40 application deployment locations on a regular basis. Instead of remembering or looking up each of these every time, DubDubDeploy kept everything organized by application and environment. If you wanted to deploy the Intranet app to QA, you opened the dashboard, scrolled to Intranet, and clicked the Deploy button under the QA server. A few seconds later, your app was deployed, and you could move on with your day. And since it was so easy, everyone could now handle their own deployments, instead of relying on one or two people to do it for them.
There were a couple more nice perks that we found along the way. Since deployments were now done server-to-server, deploying code from home, which used to be a painfully slow process over VPN, was now no different from being in the office. Also, DubDubDeploy integrated with CruiseControl.NET, so we could watch the build status in real time prior to deploying. When the build completed, the app would turn green, meaning it was safe to deploy.
The change was dramatic. Suddenly deployment became something that everyone could do, without any work at all, and without even having to know where the files actually lived. Publishing an application went from several minutes to less than 10 seconds. Adding a brand new application to DubDubDeploy could be done in minutes, faster than it would have taken to deploy the application even once by hand. We knew we were on the right track.
Unfortunately, we were not permitted to use DubDubDeploy for production deployments. The product necessarily has a requirement that opens up a new line of communication to the target server over HTTP, which was not allowed in production in our corporate environment. Even so, the majority of our time was spent in the development and testing worlds, so even without production, we were still able to save a ton of time and work.
Now that we stopped wasting all of our time dealing with permissions and servers, we freed up time in everyone's day for more actual development. Productivity skyrocketed, and morale among the developers improved. As a developer, I always prefer writing code and actually building cool new stuff, instead of overhead and maintenance, so having the opportunity to write more code was a win for everyone.
Since the product was still pre-release, the feature set was still pretty light. We suggested some new features, several of which were implemented shortly after. The product now quickly runs a differential between the source and destination directories, and allows deployment of only changed files, changing 10 second deployment into 2 second deployment. We also needed a way to make user setup even easier - instead of defining security by user, we could now add a single AD group to the configuration and never touch user security again.
It's obvious that the product is still pretty new - the UI is still a little rough, and while it's been a big help, I can think of a dozen new features that will make this even more useful. In addition to a cleaner user experience, they're planning new features like scriptable deployments, FTP deployment, source control integration to deploy branches of code, and IIS integration. The team is very responsive with comments and suggestions - as we find more potential uses for DubDubDeploy, we've been communicating these with the development team, and we're hoping to see these in their next major release.
After a few months of using DubDubDeploy to manage our deployments, there was no turning back. Deploying by hand, even in a simple environment, seems archaic in comparison.
About the Author
I am Donte Ormsby, a graduate of University of Arizona, and majored in Classics of all things. For those not familiar with that course of study, Classics is the discipline of researching ancient Egyptian, Roman, and Greek cultures, from the standpoint of their architecture, literature, and art.
I couldn't have known it back then, but my degree had an incredible impact on my current occupation. The study of Classics is essentially the study of human nature. And web development at its core is the study of human behavior. Creating a website is more than creating beautiful interfaces and code.
A web developer whose occupation is creating opportunities for businesses and nonprofits via the medium of the Internet should ultimately be concerned with how his or her creations impact the viewer who has reached the website. I personally keep my goals very simple. Design simple beautiful websites that bring customers to my client's front door.