A1 Croatia - DevOps consultancy

With the platform transformations and the aim to make their services more reliable with faster feature delivery to accommodate customer demands, A1 Hrvatska decided to adopt DevOps patterns and principles.

To achieve that, the following practices and principles were found to be best suited for the organization:

• End-to-End responsibility
• Cross-functional Autonomous Teams
• Continuous Integration
• Continuous Delivery
• Continuous Deployment
• GitOps
• Continuous Improvement

As an established DevOps consulting expert CROZ was engaged to work closely with A1 experts in making those aims come true.

By becoming a true team member, CROZ had a chance to gather a deeper insight into the current development and operations processes. With that knowledge, we found what areas needed which improvements and which current practices could be shared with other teams.

Working closely with all relevant stakeholders at A1 Hrvatska and with joint effort we managed to succeed in implementing all targeted patterns and principles, so let us dive into each one:

1. 1. End-to-End responsibility

Whenever a dev team finishes some functionality that is ready to be deployed, they pack it with the installation instructions and deliver those files to operations. From there operations are responsible for the application lifecycle.

To make sure that the application is functioning properly and to avoid a “middleman” between platform and dev teams that could delay and prolong the feedback loop, the dev teams have to be responsible for the application lifecycle. A common “throw the bomb over the wall” practice is a culprit that should be removed as it complicates problem-solving and brings a lot of communication noise that could end up in bug-fix being delivered in weeks instead of hours.

Dev teams were enabled to have full application lifecycle management (ALM) with Gitlab (DevOps pipelines), access to OpenShift console, and Argo CD. Now dev teams can manage and monitor application deployments on OpenShift with Argo CD and monitor application behavior through OpenShift console.

2. 2. Cross-functional Autonomous Teams

To make end-to-end responsibility a reality there are two options, to have T-shaped dev team members or to join dev with the ops team. Because of strict policies joining dev and ops teams was not an option. That meant that dev team members had to undergo several enablement sessions to learn how to perform full ALM on the given platform that the ops team manage.

Dev team members were onboarded on how to use the OpenShift platform and Argo CD. How to create application configuration files, configure Argo CD to use those files to provision their applications on the OpenShift platform.

3. 3. Continuous Integration

Knowing that their code builds and successfully integrates with other team members changes speeds up development and makes it more reliable. To achieve that CROZ proposed a Gitlab CI pipeline design that was accepted and became a new standard that is steadily applied to all applications.

1. 4. Continuous Delivery

Having an application ready to be deployed at any time provides enormous flexibility and speed when planning a deployment. That flexibility is achieved by a Gitlab CI pipeline job that builds Docker images on each commit to the Git master branch or merge/pull request to a release branch.

2. 5. Continuous Deployment

By implementing Continuous Delivery we implemented a key prerequisite to Continuous Deployment. With Continuous Deployment, we are getting automated delivery of the application to the test environment so that the test team can perform their tests. Implemented Gitlab CI deployment pipeline job is what that brings a hustle free deployment to test environment with just a commit to release branch. Now developers can deliver their changes to test teams in a standardized way.

Deploying to production is also automated but with the key difference, it is manual. So whenever the dev team gets the green light from the test team it can deploy the tested application to the production environment by simply approving production deployment on the Gitlab CI pipeline.

1. 6. GitOps

Having a written change trace and who/what/why performed those changes eliminates uncertainty and provides a means of disaster recovery. Every single configuration file that is written lives on Gitlab, be it application configuration or cluster configuration. Tools consuming those configurations are Ansible and Argo CD.

2. 7. Continuous Improvement

On the first iteration of our engagement, the client proposed to use the existing Jenkins instance for CI/CD and that worked good. Very quickly client recognized that Jenkins does not fit dev team demands so we proposed the Gitlab CI that is now used.

Also, we used plain YAML files for application configuration that had its advantages of being transparent. But soon we found that using Helm Charts can bring benefit both in standardization and simplicity in terms of configuring standard application parameters. Helm Charts are now a standard way of writing application configuration files.

Those are great examples of how continuously experimenting can result in finding the best tools for the job.