Every team's pipeline pushes into your TestRail-class case repository with the same machine account and the same credential. What does that cost you, and how would you break it up?

## What sharing one account actually means A single machine account pushing on behalf of everybody looks like good hygiene from a distance: it is not a person's credential, it is named for automation, and it has been deliberately created. The problem is that an account is the unit of almost everything the repository does around a write — attribution, reach, revocation and throughput all attach to it. Sharing the account merges those four properties across every team that uses it. | | One shared reporting account | One account per pipeline | |---|---|---| | Trail says | The same name on every outcome | Which pipeline wrote it | | Reach | Union of every project any pipeline touches | One project | | Revocation | Everyone dark at once | One team affected | | Rotation | Coordinated across every team, so never | Staggered, whenever convenient | | Bulk allowance | Shared, so one team can starve another | Independent | ## The four costs 1. **Attribution collapses.** Every outcome in every project carries the same author, so the trail cannot answer the one question people actually ask it: which pipeline recorded this, and against which build. You end up reconstructing that from timestamps and cycle names, which works right up until two teams run at the same time. 2. **Reach becomes the union.** The shared account must be able to write into every project any pipeline reports into, so it is organisation-scoped by construction. That means the least careful team's pipeline configuration determines the exposure of everyone else's inventory — a genuinely uncomfortable coupling, because no single team owns the credential's blast radius. 3. **Rotation couples every team to one moment.** Rotating the credential means every pipeline must pick up the new value together. That is a cross-team change with no natural owner, so in practice it never happens and the credential ages indefinitely. Revocation is the same problem under time pressure: the day you must kill the credential, every team's reporting stops at once, including teams with nothing to do with the incident. 4. **The bulk allowance is shared.** Rate limits on bulk operations generally attach to the account or credential. One team running a large import or a migration consumes the same allowance the others' pushes need, and the victims see intermittent reporting failures in a pipeline they did not change, caused by an event in a project they have never opened. It is the hardest of the four to diagnose because nothing in the failing pipeline is wrong. ## Why it is always rotation that exposes it The first three costs are livable in the sense that nothing visibly breaks. Rotation is the moment the coupling becomes a scheduling problem: someone has to change a value that lives in an unknown number of places, owned by teams who did not know they shared anything. Very often the discovery that the credential is shared *is* the rotation attempt. If your only reason to split the account is a security argument, you will lose to the backlog; the operational argument — **you currently cannot rotate this at all** — is the one that gets funded. ## Splitting it up The target shape is one account per pipeline, or per team-and-project where a team runs several pipelines into the same project: - **Named for the pipeline and project it serves**, because the name is what a reader sees in the trail months later, with no other context. - **Project-scoped**, so the union disappears and each credential's blast radius is one team. - **Independently rotatable**, which is what makes rotation happen at all: a change one team can make on a Tuesday without asking anyone. - **Registered** — a list mapping each account to an owning team, a source repository and a contact, so an incident responder can revoke a credential and immediately tell the right people their reporting has stopped. ## Migrating without a dark day Do not cut over at once, and do not disable the shared credential to find out who is using it — that is discovery by outage, and it hides exactly the jobs you most want to find. 1. Create the new accounts and hand them out, leaving the shared credential working. 2. Move pipelines in waves, starting with the noisiest so the shared account's traffic drops visibly. 3. After each wave, read the shared account's trail for outcomes still arriving, and use the project and cycle they land in to identify the pipeline behind them. 4. Wait through a full cycle of scheduled work — nightly, weekly and release-time jobs — before you conclude the credential is quiet. The job you forget is always the quarterly one. 5. **Disable rather than delete** the shared account, so every historical outcome it wrote stays attributable to something a reader can still look up.