Capability:

Write new code, while a release is in progress
Release a patch to a service quickly after a release has gone out (and new work has occurred in the service)

In trunk based to a create a new release we have:

Create a release from master
Branch for release (cherry pick commits to go into a release branch - all work is still in master)
Feature flags

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
  - Adding logic/feature? Yes
  - 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!