A long-lived Jenkins controller has grown to roughly 200 installed plugins. How do you decide what to remove, and what does removing one actually cost?

## Where 200 plugins come from Nobody chooses sprawl. It accretes: the setup wizard's suggested set, transitive dependencies of things people did choose, detached plugins added by core upgrades, a one-off integration for a team that has since disbanded, three overlapping notification plugins from three eras, and a UI plugin somebody trialled in 2018. Nothing removes plugins, so the count only rises. ## Why it matters beyond tidiness - **Upgrade coupling.** Every installed plugin's maintainer holds a partial veto on when you may move core, and one incompatible plugin can block the whole upgrade. - **Trust surface.** Each plugin is standing, unconfined code in the controller JVM, and each is a subscription to that maintainer's future advisories. - **Startup and memory.** Extension scanning and loading are proportional to the set; a bloated controller restarts slowly, which makes every maintenance action more expensive and therefore rarer. - **Migration cost.** Moving to a new controller, a container platform, or another CI system is priced by the plugin set, because each plugin is behaviour with no equivalent elsewhere. ## Measure before you cut Jenkins stores job configuration as XML, and elements contributed by a plugin carry an attribute naming it: ```bash # Which jobs reference the plugin "copyartifact"? grep -rl 'plugin="copyartifact@' "$JENKINS_HOME/jobs" --include=config.xml ``` That gives you real evidence for freestyle and multibranch job configuration. For Pipeline, the usage lives in `Jenkinsfile`s in your repositories, so search SCM for the step names a plugin contributes. Combine both and every plugin lands in one of three buckets: **referenced**, **unreferenced**, or **infrastructure** (a dependency of something referenced, or something that provides behaviour without appearing in configuration — authorization strategies, credential providers, agent clouds). The third bucket is the one that punishes naive automation, so treat "no grep hits" as a lead rather than a verdict. ## The decision, per plugin Ask in order: 1. **Is anything using it?** If not, and it is not infrastructure, remove it. This is usually the largest bucket and the cheapest win. 2. **Is it maintained?** An unmaintained plugin with open advisories is a liability whether or not it is used; that becomes a migration task, not a keep decision. 3. **Would a script do?** A great many plugins wrap an HTTP API or a vendor CLI. A single `sh` step, wrapped once in a shared library so every team calls it the same way, trades a permanent trust grant and an upgrade veto for code you own and can debug. 4. **Does it earn its coupling?** Some do, unambiguously — the SCM plugins, Pipeline, Credentials, and whatever provisions your agents. Nobody should be replacing those with scripts. ## What removal actually costs This is the half candidates skip. Jenkins does not check usage before an uninstall, and it does not rewrite job configuration to compensate. When a plugin goes: - Job XML referencing its classes can no longer be deserialized. Jenkins retains the raw XML and reports the situation under its old-data management page, but the affected configuration is inert — and if you then save that job from the UI, the unreadable parts can be dropped for good. - Jobs can fail to load entirely when the missing element is structural rather than a single build step. - Build history that depended on plugin-provided actions loses those views. So the safe sequence is: identify references, migrate or delete those jobs *first*, uninstall second, restart, then check the old-data report and the controller log for deserialization warnings. Do it on a staging controller restored from a copy of `JENKINS_HOME` before you do it anywhere real. ## When pruning is the wrong project On a controller old enough to have 200 plugins, in-place pruning can cost more than it returns: every removal is a small migration, and the end state is still a hand-made controller nobody can rebuild. The alternative is to stand up a controller built from a curated, pinned plugin list and declarative configuration, then migrate jobs onto it deliberately, leaving the old one read-only until it is retired. You get a known-good baseline and the migration effort buys a reproducible platform rather than a slightly smaller mess. A related structural move is to run **several controllers** with narrow plugin sets — per business unit, or splitting the strictly-governed production-deployment controller from the general build controller. Each stays upgradeable on its own schedule and a bad plugin has a smaller blast radius. The cost is real: more platforms to operate, credentials and agent capacity to arrange per controller, and a shared-library or template story so the split does not fragment practice. ## Answering it in an interview Give the measurement method, the decision criteria, the removal hazard, and — most importantly — a stated position on when pruning is not worth it. The senior answer removes plugins. The principal answer says which of the two projects it actually is, and what the organisation gets for the money.