#49993 Feature gating design and integration
Opened 2 years ago by firstyear. Modified 5 months ago

Issue Description

We have had a number of features land that have caused some challenges, and needed to be reverted. We should improve the process of development, review, test, enable and rollback. To achieve this we should have a feature gating mechanism, similar to how we managed enable-disable-nunc-stans. It's been done in the past, but designing and having a dedicated feature for this will allow us to develop and commit sooner, allows QE to test, and allows us to develop stronger developer confidence in changes, and control, delay releases, and to ship "quick reverts" if required to users and admins.


Reading the description I see two proposals but may be there are more. First is a process improvement (design, review, dev, push, test, doc). The second is a mechanism to control when/how the implemented feature will be used. Are there others proposals ?
I have the feeling that the result of this ticket could be a process document but not code change, am I wrong ?

Metadata Update from @tbordaz:
- Custom field component adjusted to None
- Custom field origin adjusted to None
- Custom field reviewstatus adjusted to None
- Custom field type adjusted to None
- Custom field version adjusted to None

2 years ago

Yes, this is both a process change, but in order to support the process, we need a way to technically gate the changes. I don't thing cn=config is a good idea because the change may be for cn=config. So I think we could have an alternate mechanism, read early in main() that defines the set of server features to turn on/off.

Metadata Update from @mreynolds:
- Issue set to the milestone: 1.4.1

a year ago

Metadata Update from @mreynolds:
- Issue priority set to: normal
- Issue set to the milestone: 1.4.4 (was: 1.4.1)

5 months ago

Login to comment on this ticket.

Metadata