A 30-Repo RPA Platform, From Sprawl to Standard
We decomposed a tangled automation monolith into 30-plus governed microservice repositories, hardened the CI/CD estate with DevSecOps gates, and tuned the Gardener-managed Kubernetes underneath it.
A robotic process automation platform inside SAP had grown the way successful internal tools usually grow: fast, and without anyone holding the wheel on structure. Dozens of bots, integrations and shared libraries lived inside one sprawling codebase, built by Jenkins instances nobody fully owned, deployed to a Gardener cluster that renewed its own credentials by hand. It worked, until it needed to scale. Our brief was to turn the sprawl into a standard.
The work spanned three layers at once: the source-control topology, the CI/CD and security estate, and the Kubernetes platform beneath both. None of it could stop while we changed it, the RPA bots were running real business processes every day. So the overhaul was deliberate, audited first and migrated in slices, with governance baked in rather than bolted on afterwards.
Start with an honest audit
You cannot standardise what you have not mapped. The first phase was a full inventory of the RPA GitHub project structure, the build infrastructure and the cluster, turning tribal knowledge into something written down and measurable.
- Source topology: one monolith holding every bot, library and integration, with no clear ownership boundaries and no CODEOWNERS.
- Build estate: a mix of self-hosted Jenkins, Hyperspace-hosted Jenkins and GitHub instances, each configured differently, with slow builds and no consistent security scanning.
- Platform: a Gardener-managed Kubernetes setup whose kubeconfig was rotated manually and whose manager-to-shoot node paths were noisier than they needed to be.
- Infrastructure code: Terraform configurations, templates and service config-mapping files that had drifted and duplicated over time.
Decomposing the monolith
The headline change was structural: split the single codebase into 30-plus microservice repositories, one clear boundary per service, each with its own ownership, pipeline and security posture. Press Decompose below to watch the monolith fracture into governed service repos. Each node settles into the mesh, security gates light up green, and the counter ticks from one to thirty-two. Run it again and it re-collapses, then decomposes from scratch.
monolith30+ bots in one repo
Pipelines that scan before they ship
Thirty repositories are only an improvement if they all behave the same way. We audited and optimised the Jenkins and GitHub estate, then standardised every pipeline around the same security-compliance gates so that no service could merge or release without passing them.
- SonarQube for static analysis and code-quality gates, failing the build on new critical issues.
- WhiteSource and BlackDuck for open-source dependency and licence compliance across every service.
- GitHub Advanced Security (GHAS) for secret scanning and code scanning native to the repos themselves.
- Build performance: caching, parallelism and trimmed agents cut pipeline times across the self-hosted and Hyperspace-hosted Jenkins instances.
Governance is a default, not a review. Every new RPA service is generated from a template that already ships with CODEOWNERS, the five security gates and a working pipeline. The right thing is the easy thing, so nobody has to remember to do it.
Gardener, kubeconfig and Terraform
Underneath the repos sits the platform, and it needed the same care. We enhanced the Gardener-managed Kubernetes setup so it ran with less friction and less manual toil.
- Deployment manifests: cleaned up, consolidated and made consistent across services so deployments became predictable.
- Automatic kubeconfig renewal: credentials that were rotated by hand now renew themselves, removing a recurring failure mode and a manual chore.
- Manager-to-shoot communication: tuned the node paths between the Gardener manager and shoot clusters to be quieter and more reliable.
- Terraform: optimised the configurations, templates and service config-mapping files, removing drift and duplication so infrastructure changes were reviewable and repeatable.
The part that outlasts the contract
Infrastructure decays the moment the people who understand it leave. So a large part of this engagement was deliberately about people, not pipelines. We led the hiring and training of mid-level and junior DevOps engineers and ran a mentorship programme so the team could own the new platform once we stepped back.
That was backed by comprehensive workflow documentation covering the repository standards, the pipeline gates, the Gardener setup and the Terraform layout, written for knowledge transfer rather than for a shelf. The goal was a platform the client could run without us, which is the only kind of standard worth leaving behind.
Takeaways
- Audit before you overhaul: map the source, build and platform layers honestly before touching any of them.
- Decompose a monolith into clear service boundaries, each with its own ownership and pipeline.
- Make security gates a template default so SonarQube, WhiteSource, BlackDuck and GHAS run on every service automatically.
- Automate the platform toil, kubeconfig renewal and node communication, so the team manages outcomes, not chores.
- Invest in people and documentation so the standard survives the handover.
Sitting on a platform that has sprawled?
We audit tangled RPA and microservice estates, decompose the monolith, wire in DevSecOps gates, and hand your team a documented standard they can run themselves.
Plan your overhaul