Things to keep in mind:
- Using a feature flag doesn't mean that a git branch is never used, rather it means a long-lived feature branch is never used. Short git branches (1-2 days) are perfectly fine.
- Feature flags shouldn't be around very long, they aren't to support configuration. Rather we use them in place of a feature branch. They should be removed as soon as the new feature is done.
- Feature Flags are simpler when:
- We don't make breaking changes in our API and DB.
- We only use the conditional logic in places it has to be:
- Add a field? No
- Add a UI element? Yes, hide them
- Remove a field? No see above
- Remove a UI element? Yes, hide it
- Upgrading a framework? No, unless it's trivial.
Testing
- In Java, Togglz has a library that can help
- Tend toward testing the new path over the old (the feature is enabled). This goes for contract, performance, functional, etc.
- When possible test new and old paths (switch the flag)
- Not using breaking changes will greatly help testing.
Typical workflow:
- (optional) Create a branch for code review purposes
- Create a new feature flag by adding it to the enum in Reference Data - it'll be available in Requisition, TODO: add REST endpoint for UI
- Start adding the tests, feature, etc.
- (optional) Once code review from has been passed, merge into master.
- Once feature is ready for QA, they may enable the feature in the console.
- Keep iterating on the feature until it's done and signed off. Don't forget contract, performance and functional tests.
- Remove the feature flag from all code - tests should still be passing!