Many organisations are still using in-house developed frameworks, processes and procedures to manage their deployment automation. Quite often these will have been developed and added to over many years, with the inputs of many technical resources, architects etc. and according to the new requirements of new projects as they come along. Often they will be based on scripting languages such as Bash, Ruby, Perl or Python.
THE PROS:
This approach certainly has some advantages. For example,
- All bespoke processes and requirements can be handled quite easily and according to the organisations timescales.
- Frameworks are directly under the control of the in-house IT team and require no external consultancy or development effort, or the purchase of potentially expensive software.
- The organisations own release, security, compliance, governance and control requirements can all be catered for in the in-house framework and the procedures around its use.
- The organisation does not need to be dictated to by a vendor requiring processes to change in order to make the best use of their software.
With careful controls, diligent configuration management, regular security audits and well maintained and thorough documentation, this may still be the best approach for some organisations.
THE CONS:
However, as time passes or organisations scale up, reliance on these in-house frameworks or bespoke solutions often begins to show signs of strain. Typically these might show up due to increased time required to maintain the scripted solutions, or increased reliance on a few super skilled individuals with both the knowledge of the in-house framework and of the deployed infrastructure.
Sometimes the framework struggles to cope as the deployed landscape grows, or becomes an impediment to good security, governance and control, and management of large sets of configuration data and their differences between target environments can become an issue.
As the super skilled and in-demand resources leave the organisations, often the frameworks they were involved in become ‘black box’ and either fall into disuse, because they are too complex for new resources to modify with certainty, or are rewritten which often results in a sprawl of scripts at different versions on different projects throughout the organisation. All of these issues can of course be overcome, but often with greatly increased cost or implementation delays.
DECISION TIME:
At this point, it might be wise to consider using third party tools such as RapidDeploy Application Release Automation to support your efforts. Having originally been born out of a bespoke, in-house framework at a large UK bank, RapidDeploy was designed from the outset to manage in-house frameworks as well as other technologies. Using our tool, you’ll see benefits straight away, for example:
- All activities around RapidDeploy can be carried out through a single, intuitive Web UI.
- All deployments can be monitored in real-time, with detailed logs and metrics viewable for all time as well as an audit of all activities and approvals.
- Dashboards allow the user to monitor and collate lots of deployment data.
- You can see what is deployed where, and what is different between one deployment and the next.
- You can integrate RapidDeploy with any of your other tools either through our plugins or via the REST Web Service API.
- Security is built in with integration with the organisations LDAP/AD/ADAM repositories or in our own database.
- Users can have different roles, permissions and groups giving different accesses do different project groups or different environment groups.
RapidDeploy has been tested at scale with 600 concurrent users and many tens of thousands of deployments per year. Our task based No code/Low code server orchestrations mean you can orchestrate tasks to do most activities on a server from user creation right through to deploying a complex multi-tier web application, and where you need to call a script, just do it with one of our execution tasks.
You can also bring together multiple project/target/version combinations into our graphical job plan editor and create one or more pipelines with steps between to allow manual intervention, calls to external systems or scheduled steps.
You can view and edit both through canvases on the RapidDeploy web page which means the tasks to run for a project job on any target are clear to see and manage without any of the hidden complexity often found in bespoke frameworks. All of the configuration data which might be different between targets is aggregated on one page so you can see what is different between environments at a glance.
RapidDeploy allows adoption on several levels. At its simplest, you can just run any of your in-house scripts or frameworks through RapidDeploy, but introducing security, governance and control around the process. At the next level you leverage the tasks we’ve already written to cover most processes and tools. Finally, you could write your own java based tasks and upload into rapid deploy as a plugin, with your own screens for data input.
CONCLUSION:
In-house automation frameworks often develop out of a need to manage ever growing applications and infrastructures, but over time these can start to show signs of strain. It is often at this point that organisations begin to consider vendor tools. By realising early the benefits of ARA and DevOps tools such as RapidDeploy, organisations can avoid many of the pitfalls of in-house solutions and avoid the costly and time consuming remediation required to move to a standard, built-for-purpose platform.