How to "release" a feature in milo?

[mokimo]

Description

I'd love us to gather a few use-cases and known strategies to properly release a feature in milo or see if we will need to refine the current process to support those use-cases better.

Strategy-1: Metadata

With global metadata sheets you can enable a feature in a phased-rollout strategy and can easily "revert" a change by removing the opt-in metadata field.

The ideal strategy:

• Develop feature (opt-in or opt-out)
• Test on the branch and get sign offs (Stakeholders, PMs, Engineers, QA)
  • Opt-in case: You can slowly roll out the feature and later on make this the standard
  • Opt-out case: You could exclude consumers before the code lands on stage or production.

Pro: The big benefit with using metadata to release a feature, is allowing more granular testing and having this live on stage for a longer duration if thats necessary for a diverse set of sign-offs from Stakeholders.
Con: You will need to develop this feature considering a special metadata field and likely have 2 PRs, one for developing this in an opt-in way and one to change the default.

Real world use-case:
Back when we developed the new global navigation we created a net new block which was enabled step by step on consumers until finally it became the new default

Strategy-2: Project config

Each milo project has their own consumer configs. The Georouting feature has been developed in this way and makes it possible to activate a feature for a whole project given a change on the consumer scripts & configs.
This is very similar to the metadata way of releasing features, however it makes it possible to enable features on a consumer basis.

[hparra]

I think many of us have been using metadata as a feature gate already. There may be some concern that the head of each page is getting quite large and will continue to grow.

Synching opt-in feature across all clouds becomes a problem later. How many sheets/repos do i need to touch to launch a feature?

[mokimo]

Ideally, every feature just exists or is opt-out if requested by consumers... however, there's always exceptions.

In 95% of the cases, I'd see opt-in as a strategy to launch feature A on page B on a very specific date. As merging on a specific date is something the milo pipeline does not support via a self-service Github merge workflow. Once launching on a specific date was successful, it can be rolled out as an opt-out option to everyone.