The analysts agree, uDeploy and its competitors are “Application Release Automation” tools. We used the same term on our website. Unfortunately, “Application Release Automation” is a bad description for this class of tools.
Let’s look at the three words in this term and see what fits:
- Application: Not bad. This scopes things down to software applications rather than hardware or endangered animals. The Application also indicates that we’re working at larger scope than a single tier or component, which is also ok.
- Release: To release an application, generally means to deploy it into the production environment. Certainly, production is in scope for these tools, but pre-prod environments are as well. Using the same process in prod and testing environments is a best practice. “Release” might be pointing to heavily towards production. In many companies a “Release” is scoped far larger than a single application or application group. A release can contain numerous unrelated applications. That’s not what ARA is about.
Similarly, we have shared terminology with release management. Is this tool automating a release managers job? Not really, while it can enforce some quality gates and provide better visibility it doesn’t have a detailed Release Management feature set. At UrbanCode, we even provide a specialized release management tool to focus on those topics.
- Automation: Not bad. Most people look to a tool like this when they want to greatly improve the speed and quality of their deployments by automating as much as possible.
So the problem is with “Release”. It suggests that we should ignore earlier environments and implies more of a release management role than the tools really fill.
What would be better?
We propose Application Deployment Automation (ADA). Tools like uDeploy are automating the deployment of applications.
Sometimes its a deploying to production – a release. Sometimes its one of the many deployments to the test labs that get us ready for the eventual release. What a tool like uDeploy does extremely well is let you define a standard process that is used in both environments.
Like this sort of thing? Here are other blog posts where I nitpick about jargon:
We often talk about tension caused competing bonus / success structures for development and operations teams in the build and release process. At Gartner IOM Cameron Haight framed this using the classic Prisoner’s Dilemma concept from game theory. I wanted to elaborate on that idea.
Prisoner’s Dilemma in a nutshell
The dilemma looks at the risk/reward around cooperation. A typical setup* to the “game” is:
Two men are arrested, but the police do not possess enough information for a conviction. Following the separation of the two men, the police offer both a similar deal—if one testifies against his partner (defects/betrays), and the other remains silent (cooperates/assists), the betrayer goes free and the cooperator receives the full one-year sentence. If both remain silent, both are sentenced to only one month in jail for a minor charge. If each ‘rats out’ the other, each receives a three-month sentence. Each prisoner must choose either to betray or remain silent; the decision of each is kept quiet. What should they do?
Coming back to IT
Lets imagine a bonus or annual review structure in a typical IT shop. Development is being told to be more Agile and is being rewarded primarily based on how quickly they are delivering new capability. Operations is responsible for keeping production systems running. They get a bonus if they can reduce the frequency and duration of outages. Plus, their lives are better when the pager doesn’t go off in the middle of the night.
Cameron Haight stirred the pot during his keynote talk at Gartner IOM in Orlando this Wednesday. Cameron started his talk by throwing some stones in the general direction of ITIL before moving to a pretty standard (but very well executed) of the principals behind DevOps and it’s general lack of prescriptive practices.
The kicker was how he wrapped up. He touched on the “NoOps” debate declaring that operations will still be around. The question is whether they will stay a part of their current companies or be working for the *aaS providers. Cameron suggested that unless the IT/Ops folks he was speaking to become open to DevOps and engage actively with development, they’ll quickly become replaced by outside cloud providers.
The gauntlet was thrown down. Will infrastructure and ops rise to the challenge of DevOps or take their chances?
I still hear a good deal of skepticism about DevOps. There’s an acknowledgement that it may be appropriate for small teams or startups, but some doubt about its applicability in established companies.
A recent Gartner case study by Cameron Haight* looks at an effort undertaken by National Instruments to implement a new SaaS model. NI ended up automating their deployments and configuration with a model based strategy, cloud based hosting and increasing developer-operations cooperation.
What I find most interesting in this example is how normal it is. NI started before DevOps was a well known philosophy. But when you look at the problem space of trying to deliver new products quickly, and are willing to be bold in your solution design, the same patterns appear over and over. DevOps, if anything, is a recognition of a successful pattern that has played out over and over again.
Deployment docs and manual deployments are just too slow in many real-world scenarios. So we end up needing to automate. Because infrastructure, application code and application configuration are inter-related, a model of the complete system is created and updates use that model and an automation language of some sort to apply changes. Getting to this point encourages developers and system admins to collaborate lowering the “wall” and animosity between these two groups.
Learn more about Urbancode’s DevOps Tools
Gartner Clients may download the Gartner Case Study
* ”Case Study: DevOps Used at National Instruments” Cameron Haight Nov 2011