Feature flags
Feature flags separate deploying code from releasing it: a change ships switched off and is turned on, or back off, without a new deployment.
Kinds of flags
- Release flags: hide unfinished work already in production.
- Operational flags: switch off an expensive feature under load.
- Experiment flags: compare two versions with real users.
- Permission flags: open a feature to some customers only.
Why they reduce risk
Turning a flag off is faster than rolling back a deployment, and a gradual rollout limits how many users a defect can reach.
Avoiding flag debt
Every flag is a branch in the code. Give each one an owner and a removal date, and delete it once the feature is fully released.
How DevGob applies it
DevGob does not switch flags itself. Record the flag in the Deployment's rollback plan, so the committee knows the change can be turned off without a new install.
Read it in the documentationRelated topics
Continuous delivery
Continuous delivery keeps every change ready to release: built, tested and deployable at the push of a button, in small and frequent batches.
Observability
Observability uses logs, metrics and traces to understand what a system is doing — and, after a release, whether the change caused the problem.
Change management in DevOps
Change management decides which changes need authorization, who gives it and what evidence is kept — without slowing down the changes that don't.
DevOps with governance, on one record
DevGob plans the work and governs every change on its way to production: backlog, sprints, committee authorizations, install evidence and an audit trail.