Getting configuration out of the console

Every administration console tells the same lie: that the change you have just made is under control, because you made it yourself. Six months later, nobody knows why that header is rewritten on that API, staging no longer looks like production, and the only history available is the memory of whoever clicked.

The cure is known: configuration in a Git repository, deployed by a pipeline, like code. What is missing is not conviction, it is the path. "We will do APIOps" sits in backlogs for years because the job looks like it has to freeze everything.

It does not require that. Here is the order that works.

Step 1: export, without changing anything

Before automating anything, have the complete configuration of the platform exported every night into a Git repository. Every serious gateway allows it, through an API or through a CLI.

That cron job, one working day of effort, already changes the situation: you have a history, a daily diff, and the ability to answer "what changed this week?". The day a behaviour drifts, the diff points at the change. It is archaeology, not yet engineering, but it is the end of the amnesia.

Step 2: let the environments diverge in a file, not in people's heads

Compare the staging and production exports. The list of differences is always longer than the team imagines. Classify each difference: legitimate (backend URL, secrets) or accidental (that cache policy switched on in staging "for a test" in 2024).

The legitimate differences become variables in the configuration files. The accidental ones get fixed. At the end of this step, the sentence "staging proves something" becomes true again.

Step 3: deploy one API, exactly one, through the pipeline

Pick a live API, changed regularly, owned by a willing team. Its contract and its configuration live in a repository, a pipeline pushes to staging on every merge, to production on tag. Rolling back is a revert.

A single API is enough to face the real problems: secrets, the object identifiers that differ between environments, the policies that reference shared resources. Solving them on a concrete case produces the tooling the next ones will reuse.

Step 4: close the console, scope by scope

This is the step everyone puts off, and without it the other three end up dying: as long as the console stays open for writing, it gains ground back at every emergency.

You do not close it in one go. You close it scope by scope: migrated APIs go read only for everybody, with a traced break glass procedure for incidents. Emergency access exists, it is logged, and every use triggers bringing the repository back in line.

The rules come next, for free

Once the configuration sits in Git, governance changes nature: the rules are no longer a document, they are checks in the pipeline. Naming, mandatory security, contract compatibility with the previous version: everything is verified at build time, before the platform is touched.

That is the correct order of things. Organisations that start by writing the standard end up with a document. The ones that start with the pipeline end up with an enforced standard.

How long it takes

On a medium sized platform, a hundred or so APIs: step 1 counts in days, step 2 in weeks, step 3 in one or two months with the pilot team. Step 4 takes as long as it takes to cover the estate, and that is the pace at which your platform stops depending on people's memory. The target is described in detail in Industrialise.