Deltatre Cloud Native Journey

Deltatre is a leading company in the sports industry, specialising in the creation of graphics and tools for journalism and live television broadcasts.

Deltatre’s development team was at an advanced stage within the Cloud Native Maturity Model, but felt the need for support in the creation of an easily replicable and scalable white-label project that could give a boost to automation. Initial requests included:

• to validate the ongoing implementation of GitOps as a pivotal technology for release automation, centralised project repository management and access segregation
• introducing best practices, speed and quality of release, standardising project delivery
• strengthen a multi-cloud/cloud-agnostic approach (avoiding vendor lock-in)
• optimise the local development process by making people productive within their team in a shorter time
• increase the operation-side skills of developers (Shift Left)
• increase the by-design security level of the current infrastructure (Shield Right)

Any Cloud Native Journey is a journey that addresses the entire software lifecycle and crosses the organisation in terms of processes and people, as well as technology. It is always very challenging, but in this case it was particularly interesting because of the maturity of the customer’s team with whom we worked assiduously (maturity in the sense of the Cloud Native Maturity Model).

In the initial phase, we always proceeded with a thorough assessment made up of meetings and dozens of questions to get a clear picture of the starting context and to avoid false or trivial steps. The longest meetings were fortnightly, while a quick 30-minute meeting was held weekly to assess the status of progressively agreed tasks.

For the shared journey to work, in fact, a continuous exchange of information and details and not just access to code and infrastructure is essential. This is the reason that drove us to an experiment, which we can define as successful, of constant journaling: not a simple record of the meetings, but an attempt to analyse at each step partial objectives, problems identified, solutions proposed and then implemented, until arriving at a list of ’to do’s’ that traced the direction of the backlog.

The first phase of the CNJ involved the entire operations side, specifically the bootstrapping of a new project based on Forge, a highly scalable publishing platform in Deltatre’s product portfolio. Analysing the current workflow, we identified those steps that still required manual or sub-optimal steps and could be automated. What emerged was a set of optimisation activities, resulting in an issue backlog, for which we proposed the creation of a seed IaC project that would automate and standardise, also in terms of security, all those otherwise manual steps required during the stab of a new project (such as the initial configuration of the Cloud Vendor and its repositories).

During this phase, it also emerged that the tasks to be performed by the operations team, from the initial bootstrapping of the infrastructure, the delivery of access credentials to the platform, the subsequent bootstrapping of the CI/CD pipeline, and the setup of the staging and production environments, usually took less time (2-3 weeks at most between support and optimisation) than the several weeks required for the development and design customisation of the frontend solution.

After concluding the collection of information regarding the developers’ workflow, from how the machine setup is done to how communications are integrated between the various teams, through the sharing of infrastructure and application front-end code, we concluded that the consistency between the development environment on the local machines and the development environments created internally in the pipelines should be increased, working on the creation of a local containerised environment to:

• ensure the alignment of the versions of the various software/libraries used by individual developers
• promote consistency with deployment pipelines that would share the same configuration
• ensure that developers can start their activities without having to wait until the development environment is actually ready

• automating the registration and authorisation of users on the authentication platform created for the start-up of a new project
• automating the creation of the schema with the initial structure of the Forge frontend pages
• automating the initial release phase of a new frontend module, creating some templates from which to start and speeding up the initial integration phase in the CI environment
• with a view to 'shift-left', adding active Git Hooks in the developer's local environment to automate the execution of code linting tests with SonarQube; this would allow code issues to be identified without having to wait for pipeline execution

• regardless of the specific objectives of a Cloud Native Journey, it is often the case that the desired statement of Cloud Agnosticism is often countered by ties to the present vendor that always seem to be much stronger than one realises, if only as a matter of 'we know how to handle it'
• the start-up of CNJs very frequently brings different teams to the same table, teams that despite belonging to the same company may never have had the opportunity or felt the need to confront each other before. This is an extremely interesting side effect and mostly effective in terms of resolving any communication knots or procedural understanding. To be taken into consideration