Independent Feature Release — Definition Of Done
Brief
An Independent feature release is a strategic initiative at Beamery Engineering. It allows us to manage ever-growing technology complexity, evolve platform architecture, and tackle technical debt.
The main advantage of such an approach is the easier articulation of technology evolution through value release speed instead of architecture evolution/service decomposition. Architecture evolution should come as a natural artefact of
(a) Fast value release
(b) Spawning a new team when the cognitive load overwhelms the team and hinders team output (team-first approach to architecture evolution, pls see https://teamtopologies.com/ for more details)
Definitions
Product Feature Boundary — full set of services and components required for a feature to function
Team Boundary — set of services and components team owns
Service Boundary — set of external interfaces exposed by service to clients and upstream dependencies
IFR — Definition of Done
Following conditions should be met for a Product Feature to be independently releasable:
Feature (or service ) is independently released if and only if all of the following conditions met:
- Product Feature Boundary is clearly defined and documented.
- Product Feature Boundary is a subset of a Team Boundary OR (if Product Feature Boundary overlaps multiple Team Boundaries) team interactions abstracted through API contracts
- Product Feature can be built, configured, deployed, tested, and enabled independently of other product capabilities.
- Product Feature has a feature flag and can be enabled in a controlled fashion for selected tenants or across multiple tenants for selected user groups
