Redesigning Babel’s internal development model: flying towards production

Just like in the Bible, each project speaks its own language. Some speak a more common language, such as JAVA. Others, even within the same project, speak several languages and dialects: JAVA and AngularJS, for example.

Our vision and goal was to provide a single, homogeneous software life cycle, independent to the language or languages spoken in the project, to minimise the developer’s interactions, and to automate the most tedious and repetitive tasks, ensuring the developer focuses on what is most important: developing.

With the internal priority being to create a common development and integration flow, a multidisciplinary team was formed, with two cloud infrastructure profiles focusing on the DevOps philosophy and two JAVA developers.

The first step was to design the flow of continuous integration and continuous deployment that we wanted to implement, as well as the infrastructure that provides the project with service and support.

Azure was chosen to deploy the infrastructure, this being a platform with which we are extremely familiar. As a critical service at Babel, we opted for a form of agile deployment in order to be able to quickly update or even redeploy services (or the entire platform). Therefore, the entire infrastructure is deployed with Terraform and Ansible. In addition, this code adheres to the Gitflow defined for development projects.

In order to simplify project integration into the CI flow, we sought to make the configuration as simple as possible. To do so, we developed a library for Jenkins. This library was responsible for maintaining the entire CI workflow logic. This approach provides us with a simple configuration file within the project code repository, through which we can define the type of project and the steps we want to take within the workflow in a just few parameters. This is also a modular library, so simple, minor developments can be made to add new technologies or tests. Other library functions include controlling the exchange rate used, the code version, tagging the new versions uploaded to the repository, etc.

In addition, to facilitate the integration of new projects based on micro-service architectures, a Kubernetes cluster (based on Azure AKS) was implemented, providing Jenkins with the workers required to carry out the jobs in the different projects.

This approach enables us to add QA steps to the cycle: we can add new test systems (JMeter, for example) and generate a module in the library so that the projects requiring as such can make use of these tests.

In the final phase, the system generates an automatic report with all the results (satisfactory or not) of all the phases involved in the process, which is sent to the developer or the team.

Following implementation, training and support of the different teams and projects, a continuous integration cycle was achieved that is homogeneous and common to all projects.

This step has enabled many projects to reduce product time-to-market, improve product quality, and avoid production inconsistencies.

It has also laid the foundations to begin with the first steps towards implementing CND (Cloud Native Development) techniques.