Speaking to a customer recently, I was told:
“Honestly, our favorite thing about moving to AnthillPro is that we’ve moved beyond ‘Plug-n-Pray’ deployments. You know, many of our deployments were so scary we’d have a bunch of people in the office or on a call all weekend to execute and debug the deployment and then have all hands on deck Monday morning to deal with the inevitable problems. We were all so stressed and tired that we were pretty much useless for a few days after the deployment.
That’s all gone now that we’ve automated. Most of those deployments are a 30 minute effort Friday night, and we don’t do anything special on Mondays.”
It always feels great to hear that your product isn’t just good for productivity, traceability, etc but that you’re also making people’s lives better by giving them their weekends back. But I think it’s important to call out that changes in process for this customer and others like them that are equally important.
- No more Word documents containing the deployment plan They’re hard to follow, and get out of date.
- No fixing application server configuration in Test environments by hand: Instead of fixing a broken configuration of the test environment by hand (which often results in the same breakage in Prod), the teams fix the automation to set to the configuration properly in all environments and redeploy to Test.
- Repeatable Deployments: An automation system can only deploy that which is automateable. This rules out funky processes that rely on guess work and gut checks. The process of figuring out the deployment process well enough to automate it makes the process better. (see our WebCast on using automation to shine a light on your process.
It comes down to making sure your process can be automated. Automating that process. And not circumventing the automation – even in test environments. Each of those three elements delivers some unique gains.
