Deltatre is a leading company in the sports industry, specialising in the creation of graphics and tools for journalism and live television broadcasts.
Pushing the automation accelerator to scale large volumes.
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:
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:
