Most Read This Week
Time to Invest in Deployment By @Itransition | @DevOpsSummit [#DevOps]
You can’t be sure that every one of your app deployments will be smooth sailing
By: Ivan Antsipau
Oct. 24, 2014 08:00 PM
Why Now Is the Right Time to Invest in Deployment Automation
Isn't it great to treat your girlfriend by cooking her favorite omelet every morning? In theory, sure, but in reality, chances are most of the time you end up with darn scrambled eggs instead. Let's face it: you're a great boyfriend but a terrible cook. Believe it or not, this is quite analogous to app deployment. You can't be sure that every one of your app deployments will be smooth sailing; every now and then you will mess up a thing or two (or a dozen) along the way.
Be it a critical urge to rapidly roll back to a previous release or the inability to find the phone number of that one guy responsible for deployment, the opportunities for things to go terribly wrong are endless. As a rule, there are two reasons behind your worst nightmares coming true:
In this article, we'll focus on the second point - deployment automation.
The automating software deployment process for .NET has pretty much become a ‘no-brainer' during the past few years. New tools have made it extremely easy to make deployments faster and less risky at costs tending to zero. Not using automatic deployment in 2014 is like not using source control; it's possible to live without it but having it in place keeps you safe while requiring such little effort. Yet, many still resist given their perception of the hassle around the creation, configuration and maintenance of automated deployment. And they‘re really missing out.
There are many reasons to start investing in deployment automation for .NET, including a drastic increase in deployment success rates and frequencies, but most important, it is good for business. Here's why:
Stable Manual Deployment Is a Utopia
That's only the basic list; of course, every application is unique and has a slightly different process (so your app may have additional steps or not require some of the aforementioned ones, but most deployments are similar).
All those steps may seem easy enough to perform manually without anything going wrong. Well, day-to-day experience says that deployments always go wrong from time to time if executed manually, mainly due to our nature. Humans (particularly creative people like developers) are not very good at performing routine repetitive tasks; that's why we have computers. Here are a few examples of some of the most avoidable manual deployment errors I've seen:
You get the idea. I have no doubt you've encountered some of the aforementioned errors and can easily add a ton of others. The key problem with these errors is the fact that it's very easy to make any of them but very hard to get to the bottom of them. As a rule, it takes a lot of effort and nervous hours to detect and fix them.
Therefore, you are forced to have either a deployment document (checklist) or a special "deployment" guy on your team (or both). Each of these approaches has major drawbacks:
These issues will not occur if deployments are done automatically, because computers are good at repetitive tasks (humans are not).
Time Is Money: Gain Both
In my experience, carefully going through a deployment process manually takes at least an hour for an average developer for a small project. In an agile environment, you usually want to have frequent deployments to QA/UAT platforms, so features are delivered and validated quickly (i.e., have 3-4 QA deployments per week [meaning manual deployment costs you at least 12-16 hours per month]). On the other hand, configuring automated deployment for a simple project rarely takes more than 16 hours, while deployment itself would then be just a click away. It truly is as simple as that; automation wins even with a tight time frame. Now add up time needed to train new developers to do the deployment plus time spent to troubleshoot deployment errors. It turns out that you can save about 25-40 hours per month with automation, which translates to about $500-800.
Another important aspect is the fact that overall team performance increases, because the QA team does not need developers to be distracted from new features when QA needs a new build to be delivered for validation which; this, in turn, means greater flexibility.
Take a look at this graph from McConnell's "Software project survival guide":
The longer it takes from introducing an error to its detection, the more time (and money) it takes to fix it. Being able to deploy without a developer's involvement means much more frequent deployments, which means much quicker error detection (i.e. allows your team move even faster!).
It's also about making errors less risky, which again means higher deployment frequency. And higher frequency entails faster feedback from testers and end users.
But there's more. If done intelligently, deployment automation also provides for automated reporting into the process, which results in zero efforts and money put into complying with audit requirements, and a significant unlikelihood of audit failure.
Sound too good to be true? Here's a summary of what our team achieved in terms of ROI when we introduced deployment automation in one of our .NET projects:
And that's just a simple case. For complex projects/projects with high deployment frequencies, teams can save more than a thousand of hours per year.
New Opportunities Made Possible By Deployment Automation
I personally think the second reason is the most important for business, because of the following:
Everybody knows it is cost-effective to automate regression checks. Nowadays, we have plenty of cool tools to help implement integration tests. A good suite of UI regression tests is crucial for long-running projects' sustainable development; otherwise, in a year or two, you get to a point when you can't add new features because you are in a constant rush fixing the old ones. Automatic deployment is required in order to run these tests frequently and in an automated fashion. I recommend running them throughout the day (ideally - for every check in) - this saves money and helps you keep up with the schedule as you detect errors in under an hour from introducing them (see graph above).
Everybody wants visibility in agile development. The sooner you get something done and give it to product owners/target users, the sooner you understand what they actually need from the software (so you eliminate "you built exactly what I asked you, but it is not what I need" situation). A great way to provide visibility at no cost is to set up a nightly build, which deploys the current development version to a test environment just for reference. That way, everybody who is interested (stakeholders, managers, beta users, etc.) can see what has been built on a daily basis.
If you want your team to get into the DevOps world, be ready to invest in deployment automation. Developers tend to not like ops tasks, but they love automating stuff (that's why we automate email replies and program our coffee maker to run every morning). So a boring task to configure a new UAT platform becomes a challenging, exciting thing when you want to automate it.
Continuous deployment, where every change that passes automated testing is deployed to production automatically, has been gaining traction over the last few years with most major tech companies adopting it (WordPress, Google, Facebook, Amazon).
Standard workflow with automated acceptance (integration tests) employed.
The bottom line is there is no excuse these days to not to do automatic deployment on .NET web projects. Technology is mature and easy to use, it saves time and money, it eliminates hard-to-troubleshoot errors because the process is reproducible and versioned, and it allows your team to be more flexible and move significantly faster.
Reader Feedback: Page 1 of 1
Subscribe to the World's Most Powerful Newsletters
Today's Top Reads