At Info Rhino we have taken automating releasing software very seriously.
So seriously, we have written our own software to do this.
Small businesses need to automate releasing software just as much as large enterprises yet have fewer resources to do so.
Large businesses have multiple teams focusing around different steps in the deployment process. This often results in duplicated processes, significant manual intervention, meetings, and runbooks to try and ensure a higher environment's integrity is preserved.
We wanted the deployment process to be understandable to technical and non-technical staff alike. We wanted staff to be able to set up their own routines, which could be absorbed into other team member's processes. We never intended to replace more established Continuous Integration and Test Automation software. Instead, we wanted to have a mechanism which was lightweight, powerful, and flexible.
Batch Automation Enterprise Software, whilst very powerful, is a skillset in itself. Indeed, many larger technology departments have a team dedicated to production support of this software, and a DevOps capability which mirrors that.
We wanted to add confidence to the release process, and reduce the amount of low-level and esoteric configuration needed.
We wanted the Development Testing team to be able to work closer to their area of knowledge, not be hamstrung by having to understand yet another complicated technology.
Docker, Kubernetes, Rancher, to name but a few, are excellent examples of using containers to manage deployments to nodes, clusters, and servers. They are often cloud based, and many cloud providers have created their own wrappers around them. There is a challenge to these platforms, and are often another unique set of skills required before simple automated deployments can be set up.
Partly by how our software is managed and deployed, we felt the container based orchestration process was too big a leap for our size of company. Indeed, our software can build the code, that builds the container.
We have worked with containers and more commonly virtualisation. Both are excellent strategies for isolating environments and protecting the sanctity of higher environments to permit integration testing, prior to productionisation.
Continuous Integration sets automated deployment as its objective. Checkpoints such as unit tests and data testing, once passed can permit automated deployment to higher environments. User Acceptance Testing (UAT) can be automated into software to provide additional Quality Assurance (QA) to the release process.
Frameworks we have worked with include; HP Quality Center, Serena, Jenkins, TeamCity, Bamboo, JIRA, NUnit, Xunit, NBI, Redgate, to name but a few.
CI Tools are an incredible way to give assurance and confidence to software release processes, reducing operational risk (human error).
We still find CI frameworks to be an extra leap, an extra deep dive into overburdening the development team too early.
An honesty box moment - we just spent one week fully automating our web application deployment. We had a number of goals, including;
Our approach is to put most tasks into batch files. We set up a sequence of steps. Once confident the basic process works, we then do the following;
Additionally, we added archiving and target server management steps to fine-tune. We could easily add in test automation too.
For bullet-proofing of releases, we recommend using Log File Analysis Tools. Whilst outside the scope of this document - detecting errors in trace/log files is a powerful way to interrupt deployment when errors occur.
The result is that whilst still being a challenging process we have a repeatable process which is more closely aligned to the original software being developed. There are less steps to worry about. The DevOps team can work with these deployment artefacts. The flexibility is that smaller enterprises (larger too) may choose to use our IRPA all the way through to production. Some enterprises may choose to use our software to aid their release process, even to the point of generating their releasable artifacts.
Our personal experience is we can focus purely on the task at hand. Avoid getting up in the challenge of having to learn other software. Whilst IRPA still has to be learned, it is less destructive, more decentralised, and hence less risky.
We version our configuration too, further reducing risk.
Many files are generated which can be stored in a structured format for analysis, to aid understanding changes.
When faced with automating our deployment, we were stuck between the archetypal - "Rock and a hard place". We did not feel certain software was ready for automating, but once that leap was required, doing so proved too arduous.
We spent significant time exploring many solutions, many of which we have used on multiple client projects. We felt these external solutions were amazing, but multiple steps away from the "Jobs to be Done". At certain points, our software wasn't ready for cementing into full release cycles and so IRPA gave us a more lightweight way of automating with less pain.
Our IRPA platform uses no programming - so no code. IRPA focuses on using configuration only to generate new artiacts. These artifacts can be executables or configuration.
The outcome is a solution which gives clients a powerful advantage in simplifying deployment automation.
We recommend taking a look at this article https://geekflare.com/container-orchestration-software/. It summarises container orchestration frameworks.
Written with StackEdit.