1) All releases performed manually
2) Some scripts have been written
3) A LOT of scripts have been written
4) Some tooling has been written around the scripts to provide things like a GUI or integrations to other tools e.g. for configuration management or build engines
5) A vendor developed tool is implemented
We consider a vendor’s tool to be the optimum solution as organizations will benefit from:
- The many man-years of development the vendor has already expended on the product
- The vendor’s polling of customer/prospect base and analyst opinion for new features for the product roadmap
- The vendor’s dedication to the product and its roadmap
- Taking advantage of new features added for new customers
- Formalised, enterprise-standard support and maintenance
We appreciate it can sometimes be difficult to justify further investment in tooling if in-house resources have already been applied to partly resolve the problem and we are well-versed at Ranger4 in performing a gap analysis of existing capabilities to ARA vendor tool capabilties and working through a business case accordingly.
Repeats deployment process through Route-to-Live
A key benefit of ARA is consistency and predictability - you should be able to create a package of code and configuration that you can push through all of your environment stages through to production and know what, if anything, has changed between the stages.
It’s likely that you’ll have complex application stacks with multiple technologies - for example you might have a Java application running on an Oracle database in an IBM WebSphere Application Server cluster using IBM WebSphere MQ and Integration Bus. You should just be able to create one deployment of your application made up of its multiple components.
Graphical User Interface
Not only should you look for an GUI (browser based) that is clean and easy to use, most enterprises also will want tools that don’t require specific programming knowledge to use and that don’t use scripts. The GUI may also be able to help you graphically visualise your environment and application infrastructure aiding in ongoing architectural decisions.
Pre-built task library
As above, one of the key tenets of ARA is to move away from manual and script based processes that are error-prone and difficult to troubleshoot and audit. Finding a tool that has pre-built tasks that can be selected and added to a configuration package for deployment provides a faster, more flexible and consistent release mechanism than a deployment framework product that relies on input of difficult to manage and unpredictable scripts.
One of the key benefits of an ARA tool is the elimination of bottlenecks as you allow your development and operations teams to collaborate effectively through the release process. This demands, then, that all of the characters (developers, system administrators, DBAs, security, testers, release managers, configuration managers etc) have access to the projects and environments they are involved in - and not the ones that they aren’t. The security model needs to be fine-grained, customisable to your unique requirements and will also provide be key to you being able to prove to your auditors that your process is fully compliant (particularly around areas such as segregation of duty).
Breadth of support
Enterprises generally have heterogenous systems that have developed over time with multiple integrations, application servers, different flavours of databases and a multitude of applications. It’s important, then, that the tool you choose has support for all of the application platforms that you deploy to, or a way of you to easily create the plugins you need for them and the other components of your Continuous Integration (CI) server, DevOps or Continuous Delivery (CD) toolchain.