Feature development branch/toggle capabilities

[garagatyi]

Description

While the most widespread practice in the project for the development of a feature is to use a long-living feature branch it might not always be the best options.
Another popular solution for development of a feature is Feature toggle. Here is a great and detailed explanation of the thing, use cases, and techniques by Martin Fowler https://martinfowler.com/articles/feature-toggles.html
I thought that contributors and maintainers were free to choose a technique they prefer but figured out that we need an agreement on that here.
Personally, I and other team members struggled a lot because of lack of agreement whether we can use feature toggles or not.
Feature toggle technique can tackle a lot of use cases such as:

• Experimental features that can be tested on different stages of CI/CD or different members of the community
• Intermittent state when a couple of versions of the same functionality exists and helps migrate users, tests implementation with canary releases, prove the affect new implementation does to the project
• Operational toggles that can help ops to mitigate some issues on production (overloaded systems, some infra outage, etc)
• And even alternate different functionality for different groups of users (see permission toggle in the article)

[benoitf]

+1 for using toggle on experimental stuff !

[gazarenkov]

@garagatyi happy to see you follow it :)

My suggestion is: start systematically but small, let's say on "experimental features toggling" would be a good problem to solve (that's what we discussed initially in fact).
I'd consider IoC and component model we have is a good basis to use as a foundation.

[skabashnyuk]

@benoitf @garagatyi . You are talking about nice things. It would be even nicer if they become more technically concrete. For instance, I may understand it in terms of Theia plugins your words as beta releases. However, from the things that Alex is mostly working, where there is no strong isolation it can means - "Lets put in production code everything that becomes compiling and call it feature-toggles"
Do you have any concrete things to propose?

[garagatyi]

Actually, feature toggles allow to control whether the experimental code is enabled on production, so I see no issue here as far as it is well tested, reviewed and designed.
Apart from that this issue is not about my or Florent's contributions, it is about a general convention. I created it because @gazarenkov suggested to discuss it as a separate topic.
Because this is about the convention I don't know what exactly you want to discuss from the technical perspective. Please, elaborate.
If you are asking about concrete things I just want to figure out whether this technique is allowed or not and prevent situation as we had before when a team wants to use feature toggle technique and someone doesn't allow to do that because of his personal preferences and willingness to do things his way.

[skabashnyuk]

I'm not sure I understand your point of discussion.

1. Should we discuss big changes with stakeholders before merging? - yes
2. Can we split a big task into small steps if that possible and merged it - I guess yes in case if [1] is ok.

Is there anything else?

[dmytro-ndp]

Please, take into consideration that Feature Toggling makes acceptance (E2E) testing much more complex because we need to test behavior of system by having all possible combinations of feature flags. Ideally we will need to have separate CI QA jobs for each possible combination (multiplying on 4 types of possible Eclipse Che distribution (Singleuser or Multiuser + deployed on OCP or Docker)) to run dedicated subset of selenium tests against it.

You can find more info about that point in section "Feature Toggles introduce validation complexity" of article https://martinfowler.com/articles/feature-toggles.html mentioned in description of issue.

[garagatyi]

@skabashnyuk I was told that we need a discussion regarding usage of feature toggles, so this is the reason for the issue. I agree with the points from your last comment.

[garagatyi]

@dmytro-ndp yes, I know about this burden and we would have to deal with that in case the code would be available to users. But since not all the flows merge code that is available to users it is up to the author of the contribution and reviewers to agree on what should be tested and how.

[benoitf]

@skabashnyuk I was not talking about theia plugins when saying that toggle is a real benefit as we've early feedback on features and merge small changes every time.

I assume to test any feature on che on che.openshift.io using a toggle.

[gazarenkov]

@dmytro-ndp well, I do not think it is the same expectations, i.e. we hardly would plan a release with switched on experimental features.

[slemeur]

Feature flag capabilities would be absolutely valuable for the community and anyone involve on Eclipse Che.

• It's an interesting way to introduce new capabilities. They can be delivered in an experimental mode along with the development.
• It avoids silos and branches that are living during long long time.
• It exposes the work that is in progress and allow any contributors/users to see the progress
• It is a way to collect early feedback!

That would be definitely valuable for Che moving forward.

[dmytro-ndp]

@gazarenkov: if user will be able to switch on some experimental feature in released version it would be better to ensure that it works correctly.

[garagatyi]

If a user knows how to enable an experimental feature (it is good practice to have a unique toggle for a feature, so user can't enable all of them) and want to try it it's great. He will provide an early feedback. And since he enabled the feature manually it is totally clear that he is ready to face some instability to check it out.

[gazarenkov]

@dmytro-ndp yep, it would be, in ideal world ;)

[garagatyi]

I created an issue #10470 to integrate Unleash in Che. This will allow us to use it on wsmaster and other clients. Unleash also has official Golang, JS clients, and REST API, so we would be able to benefit from it on UD, Theia and other sites.

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.