Owning the critical path: compatible plugins for proprietary software used worldwide
A platform built on globally used proprietary software leaned on around a hundred third-party plugins and a legacy core nobody could rebuild any more. We wrote our own for the parts that matter and built a pipeline that proves every build against each release before it ships.
At a glance
- 13
plugins authored in house
- 189
tests on the proxy plugin
- 29
services the core plugin is deployed to
- 102
plugin builds banked and indexed
The challenge
The network depended on dozens of third-party plugins and a monolith of legacy in-house code whose binaries could no longer be rebuilt as the vendor's software moved on. Every version bump was a bet on someone else's release schedule.
Rewriting everything wasn't the answer. Owning the critical path was: the proxy, the entry services, the store and roles, with everything else run under strict control.
Architecture
Swipe to explore the diagram
Every jar is built fresh, hashed and indexed, then proven on a rig that runs exactly the plugin set the target server runs.
What we built
Authored plugins
- A Velocity proxy plugin that replaced five third-party plugins, with 189 tests across 44 test classes
- An entry-service plugin that replaced five more, so a seasonal reskin is just a file upload
- The core plugin: role menus, the store, loyalty streaks and service heartbeats
- A compatibility bridge so legacy backends still look like the retired core to everything that depends on it (76 of 76 contract checks)
- Restoration tooling, chat controls and more
Delivery
- One Maven codebase with a legacy profile, so services on old releases build from the same source as current ones
- Every build recorded with its commit and sha256, and our own plugins always built fresh from origin
- A compatibility matrix, over 2,000 lines long, stating exactly which jar runs where
- Deploy bundles staged on an operations box on the LAN, never on the production instances
Standards
- A plugin scaffold, a Java coding style and a versioning standard both developers work to
- Self-healing YAML config, so upgrades add new keys without trampling an operator's edits
Engineering decisions
Vendor it or drop it
Where we used a fraction of a dependency we vendored the part we needed or wrote it ourselves. We keep 36 upstream sources and 7 maintained forks for the ones that can't be replaced.
The boot log is the version of record
Filenames lie. The version a server reports when it starts is the one we trust, and there's exactly one jar per version.
Bridge, don't break
Retiring the old core would have broken every plugin that called it, so a bootstrap bridge presents itself as the old core and the dependents never noticed.
Tests to a budget
Each invariant gets a test and a script holds the test-to-code ratio inside a budget. The suites stay meaningful rather than merely large.
Outcome
The proxy plugin has carried both production proxies since September, the entry-service plugin is live on four entry servers and the core plugin is deployed across 29 services. The legacy core is retired.