Learn · Handover

Leaving it runnable

Everything you configured is discoverable. The customer’s team can read the agent configuration, the pipeline files, the cluster settings. What they cannot recover from the system is why any of it is that way.

Document decisions, not state

State is already documented, by being the state. Six months on, the question is never “what is the configuration” — it is “can I change this?”

So write down, for each significant boundary:

• What it is separating, and why that separation mattered
• What would justify adding another one
• What would justify removing this one
• What breaks if it goes away

“There is a separate deploy queue because agents in it hold production credentials and run with no-plugins; merging it into the general queue would put those credentials on machines that run pull-request builds” is worth more than any diagram. It tells the next person what they are allowed to do.

Credential handover

Enumerate explicitly, because these are the things that quietly stay yours:

• Agent tokens — who holds them, where they are stored, when they expire. Anyone with one can register an agent and receive jobs.
• Secrets integration ownership — who administers the secrets service, who can grant a new pipeline access to a credential.
• Buildkite organisation access — which of your accounts still exist, and who removes them.

Rotate anything you personally held. Not because you are untrusted, but because “which credentials did the partner have?” should have the answer “none, as of the handover date” rather than a list somebody has to reason about.

The test

The handover is complete when the customer’s team can, without contacting you: add a queue and explain why, onboard a pipeline, diagnose a job that is waiting, and rotate a credential.

If any of those requires you, you have not finished — you have just stopped.