Establishing feature ownership

Every definition is a file, so your Git host can name who owns it. A CODEOWNERS file asks the right team to review each change, and branch protection makes their approval required.

This page uses GitHub's code owners. GitLab and Bitbucket have the same idea.

Name the owners#

Create .github/CODEOWNERS and list each file or pattern with its owners:

features/checkout.yml @checkout-team
variables/checkoutSettings.yml @checkout-team @payments-team
segments/payingAccounts.yml @billing-team
attributes/plan.yml @billing-team
variables/checkoutNotices.yml @marketing-team

A change to checkout now asks the checkout team to review it, and a change to checkoutSettings asks both teams. Owners need not be engineers: the marketing team that writes the checkout notices approves every change to them.

Give each team a directory#

Listing files one by one does not scale. With namespaces, each team keeps its definitions in its own directory, and one line covers them all:

features/checkout/ @checkout-team
segments/checkout/ @checkout-team
variables/checkout/ @checkout-team

features/checkout/express.yml, the feature checkout.express, then belongs to the checkout team automatically.

Own a release lane#

With sets as release lanes, a lane can have owners of its own. Here QA approves anything that reaches production, including promotions:

sets/dev/ @checkout-team
sets/staging/ @checkout-team
sets/production/ @qa-team

Require their approval#

Code owners are only asked to review until a branch protection rule requires their approval. In the repository's settings, add a rule for your main branch and turn on "Require review from Code Owners". From then on, a definition cannot change without its owners' approval.

Ownership and tags#

Tags decide which targets, and so which datafiles, include a definition. They say nothing about who may change it, and attributes and segments have none. Ownership belongs in CODEOWNERS.

Related#

• Namespaces
• GitOps
• Sets