A toggle’s life
From defined to deleted, across many applications
Define analyst or developer
A new toggle starts pending — off everywhere until its code is in place — so everyone sees what's defined but not yet built.
Implement developer
Code and toggle together in the repository; marked implemented; promoted into the first environment.
Test and promote testers, release managers
Switched and tuned in each environment, promoted upward with its state.
Release release managers, operations
The release toggle is switched on in production.
Retire developer
Once the decision is final, the code stops checking it and it's marked retired. It still answers as before — higher environments may still run the old code.
Delete everywhere once confirmed in production
One action removes it from every environment at once. Refused while any environment still has it implemented — it can never disappear ahead of the code.
- Many repositories, one FTF. Each application's toggles live in its own repository; a toggle belongs to exactly one application by its name, so two repositories never disagree about it.
- Release toggles are shared across applications. What a shared release contains is a product decision made up front, not something each application settles on its own.
- A developer's only write to FTF is promoting from local into the first environment. Above that, promotion is a deliberate step by the people your permissions name.
- A conflict when promoting is the exception — a decision that didn't land everywhere, or requirements that changed. FTF shows it and writes nothing.
- A toggle defined before it's built is safe: pending answers off, whatever its switch says.