Case studyGaming & Betting

A new CI platform for some twenty teams.

Delivery Engineering at ATG runs the CI/CD flows for some twenty development teams delivering products for one of Sweden's largest betting operators. The assignment: introduce Drone and Harness CI together with GitHub as the new CI platform — and make it easy for other teams to lift their projects to AWS themselves.

ClientATG
PeriodMay 2019 – Feb 2021
RolesDevOps, Delivery Engineer
01 / Problem

The delivery chain became the bottleneck, not the code.

Some twenty teams deliver against a regulated betting platform where downtime and faulty releases aren't an inconvenience but a business risk. When every team builds its own path to production, the sum becomes hard to oversee: different tools, different quality bars, and a central function that becomes a dependency in every delivery.

Merely centralising would have moved the bottleneck, not removed it. The assignment was therefore framed as self-service: teams should be able to lift their projects to AWS on their own, on a shared CI platform, without queueing behind anyone.

ConstraintRegulated market: traceability and control in every release.
ConstraintSome twenty teams with different stacks and different cloud maturity.
ConstraintNo central function may become a mandatory middleman in every deploy.
ConstraintPlatform incidents hit every team at once.
02 / Approach

A shared path, their own hands.

Drone and later Harness CI together with GitHub became the shared CI platform. Around it, the things that make self-service possible were built: Terraform and Ansible for environments, Nexus as artifact repository, SonarQube as quality gate — and monitoring that spots problems before the developers do.

May 2019Into Delivery EngineeringThe assignment started in the team that runs the CI/CD flows for some twenty development teams — responsible for the path to production, not the products.
2019Drone CI with GitHubDrone CI was introduced together with GitHub as the new CI platform: a shared path teams could adopt without building their own infrastructure.
2019 – 2020A path to AWSTerraform and Ansible made it easy for other teams to lift their projects to AWS — ECS and later EKS as the runtime.
2020Metrics and monitoringWeb services in Python and Go export key metrics to Prometheus, monitored in Grafana to catch incidents proactively.
2020 – 2021Harness CI and mentorshipHarness CI complemented the platform, and teams were mentored in Nexus as artifact repository and SonarQube for code quality.
The principle
The goal was a cloud-mature organisation that can stand on its own — not a team everyone has to ask.
03 / Platform

Five decisions that carried the rest.

DecisionWhyConsequence
Drone/Harness + GitHubA shared CI path was the precondition for standardising quality and traceability.Teams stopped building their own pipelines; the platform became something you use, not something you carpenter.
ECS, then EKSNeeds grew from simple containers to teams wanting control over their own workloads.More control for the teams, but a bigger platform responsibility to maintain.
Terraform + AnsibleSelf-service requires that whoever needs an environment can raise it — not order it.The path to AWS became code teams could reuse instead of a support-ticket queue.
Nexus as artifact repositoryArtifacts need a shared source for releases to be traceable in a regulated environment.Builds reference the same artifacts through the whole chain.
SonarQube as a gateCode quality must be measurable when twenty teams deliver against the same platform.Quality became a visible threshold in the pipeline instead of an opinion in review.

Monitoring before the incident

Web services export key metrics to Prometheus, visualised in Grafana. The point is the direction: the platform team sees the anomaly first and fixes it proactively — instead of hearing about it from a team whose build is already stuck.

Step 01Metrics exportedWeb services expose key metrics from the platform's parts to Prometheus.
Step 02Collected in PrometheusTime series per pipeline, run and environment instead of point-in-time alerts.
Step 03Visualised in GrafanaThe platform team sees anomalies and trends in the same view.
Step 04Fixed proactivelyThe incident is handled before it hits the developers' builds.
04 / Mentorship

The platform is half the job. The habit is the other half.

Tools nobody uses correctly just create a new kind of bottleneck. That's why mentorship was part of the assignment: teams were trained in Nexus as artifact repository and SonarQube for code quality, and in taking their own projects to AWS.

ArtifactsTeams learned Nexus: where artifacts live, how versions are referenced and why it matters for traceability.
Code qualitySonarQube was introduced as part of the pipeline — metrics the teams follow themselves, not a report someone else reads.
Cloud maturityThe goal was teams that lift their own projects to AWS and can stand on their own after the assignment ends.
05 / Outcome

Faster delivery, fewer bottlenecks.

Teams on the platform~20Development teams delivering products for one of Sweden's largest betting operators.
Deploys per week— per week —Release cadence before and after the new CI platform.
Lead time— commit → prod —Time from commit to production, measured over the period.
Teams migrated to AWS— count —Projects the teams themselves lifted to AWS during the assignment.
Dashed boxes lack a verified number — no estimates are published.

Qualitatively, the result was a cloud-mature organisation: faster delivery, fewer bottlenecks and teams taking their own projects to AWS without central hand-holding. That the assignment could end is itself part of the outcome — the platform remained standing without its builder.

06 / Technology

Twelve technologies, grouped.

Cloud & runtimeAWS ECSAWS EKS
InfrastructureTerraformAnsible
CI/CDDrone CIHarness CI
LanguagesPythonGo
Quality & observabilityNexusSonarQubePrometheusGrafana
Say hello

Got a problem worth solving?

Chat with us on WhatsApp. We reply within 48 hours.