Inversis Reinvents Itself.

Inversis goes all in for the latest in technology and agilism.

Reinventing oneself is always a good bet for any company. This was the case of Inversis, a leading company in Spain in service outsourcing for financial institutions. In order not to fall behind, Inversis made the decision to migrate from shell scripts to Red Hat Ansible playbooks, a great idea whose purpose was to harness the full power of these tools.

And this is where Paradigma came into play. We helped Inversis to explore the Red Hat ecosystem (Ansible and Ansible Tower) and hence to benefit from all the advantages these tools provide.

Our main challenge was to get the tech support staff – who were elbows deep in the task of maintaining the platform – to gain more knowledge in order to make the most of those tools’ capabilities – following methodological guidelines based on good practices and steering development towards proper governance of the operations.

The main advantages of this model are a reduction of the associated risk through the elimination of human tasks; controlling changes; unit testing of tasks; and reusing past code, which have a significant, positive effect on scalability, the TTM and cost reduction.

We worked with Inversis in the migration from shell scripts to Red Hat Ansible playbooks in order to harness the power of the Red Hat tools to keep the complexity of the change under control.

Shell scripts have quite a few drawbacks, and Inversis could minimize or eliminate them by using the tools it already had.

Inversis needed help in making the most of the Red Hat ecosystem (Ansible, Ansible Tower, and CloudForms) and get all the advantages it has because its people did not have a good grasp of the tools.

• Centralize all the code used in a single repository.
• Keep control of the versions of each component.
• Considerably reduce the amount of repeated code in different versions of the same script
• Simplify and unify the logic applied in the migration from scripts to Ansible playbooks, which reduced the difficulty curve for maintaining them and improved readability.
• Apply good development practices (CI/CD, tests, mocks, past environments) in the development of playbooks.
• Fully create and reconfigure test/lab environments.
• Make credentials secure in order for them not to be openly stored in scripts.

• Make use of GitFlow during development, implementing a review by the team, and thus reduce errors and ensure code quality.
• Document each playbook in its own repository so that any member of the team can use it without having prior knowledge thereof.
• Take full advantage of all the possibilities afforded by Ansible and Ansible Tower; we even discovered limitations in them, which we duly reported to the manufacturer.
• Improve the management of the configuration by keeping configuration files in the repository and their versions under control.
• Make the Inversis team capable of autonomously migrating the scripts thanks to what they learnt about the Red Hat ecosystem and about the complexity of development.

Another challenge was introducing an agile-based working framework in order to be able to work with Inversis and get ongoing feedback from it. We kicked things off by introducing its staff to Scrum and discussing its key concepts during training sessions.

The Inversis working team participated very actively in all events. Thus, the client – which was just another team member – knew first-hand about the progress that was made and the dependencies that arose every single day.

We saw results on a sprint-to-sprint basis. The Inversis team increasingly relied on the tasks that needed to be done and became more self-reliant.

We can honestly say that it was a very satisfactory experience for us, that we would not have been able to achieve success without the involvement of the Inversis team, without their willingness to learn and help... In short, they let themselves be guided by us and trusted us, and we did not disappoint them.