Hi Amit,
thanks for starting the discussion. I think, there is no question about
having support for toggles. Is a little bit unclear to me what in your
project is the relation to OSGi? Is there any integration with toggles
and lets say the OSGi framework? If you could elaborate on this, that
would be great.
Regards
Carsten
On 06.03.2020 15:29, Amit Mondal wrote:
Hi Thomas,
Thanks for your quick feedback. The spec you mentioned is similar to this
project [1], Peter worked on. This addresses the problem with the start levels
- non-dynamism. Many developers start trying to control the bundle start level
when they run in timing dependencies. Since, in OSGi, we always support dynamic
behaviour, such a solution to use start level is not encouraged. The Condition
Service (as specified in RFC 242) addresses a similar problem. On the other
hand, feature flags addresses high-level enablement/disablement of a flag,
allowing teams to modify system behaviour without changing code. This can help
the team in making more informed decisions about a feature, shortening the
release cycle, performing A/B testing, and empowering people other than
engineers allowing them to control releases, among others.
This also enables you to have a very well established feature flag life-cycle
management, ensuring platforms remain stable over different feature flags
combinations and the testing complexity that grows harder and harder with each
new flag.
I would really like to further discuss if there exists any scope to collaborate
on an implementation for such feature flags integration.
Thanks and Regards,
Amit
[1] -
https://github.com/aQute-os/biz.aQute.osgi.util/tree/master/biz.aQute.osgi.conditionaltarget
________________________________
Von: Thomas Watson <[email protected]>
Gesendet: Freitag, 6. März 2020 14:52
An: [email protected] <[email protected]>
Betreff: Re: [DISCUSS] Project Contribution to Apache Felix
Hi Amit,
This sounds like it is trying to solve a similar problem that an OSGi R8
spec proposal call "Conditions" is trying to address with RFC 242 [1]. It
would be good to understand how the two approaches differ. If they are
solving similar issues then perhaps it would be better to collaborate on an
implementation of the proposed condition factory in Felix. The Condition
specification is going to impact the SCR implementation also, so the Felix
project will need to react to the Condition specification regardless.
Tom
[1]
https://github.com/osgi/design/blob/master/rfcs/rfc0242/rfc-0242-Condition-Service.pdf
On Fri, Mar 6, 2020 at 7:25 AM Amit Mondal <[email protected]> wrote:
Hello, everyone:
I am writing this email to propose a project I did work on earlier. The
project introduces support of feature flags for the OSGi environment.
Probably many of you already know about feature flags or feature toggles. I
would like to further elaborate a bit for those who are not familiar with
it.
It turns out that when many people hear the term feature flags, they
fixate on the word - flag and are thinking of something much older - other
flags in software engineering. They are referring to a compile-time flag or
a server configuration flag or maybe a server configuration file. While
those are indeed flags, what they all have in common is that they are
global. What I mean by that is they impact every user passing through that
piece of software.
But when I say feature flags, sometimes called feature toggles or
ops-toggles, I’m talking about a very different thing. I’m referring to
making a dynamic decision in my code - live. I’m deciding which way I’m
going to send a user, without having to push new code and without having to
change a config file. It’s not static, like those other examples of flags.
It’s a user-by-user, session-by-session decision.
The key benefit of using feature flags is that they decouple development
from app releases. This means two things:
* features can be merged before they are fully implemented
* fully implemented features can remain hidden until you are ready to
release them
First and foremost, feature flags help developers because incomplete
features can be merged! This allows to split a feature into many small
increments and merge those branches one by one.
Secondly, feature flags also help with releasing. In the old days, an app
release could get blocked when finding a last-minute issue on a new
feature. Thanks to feature flags, this can no longer happen! If a feature
isn’t fully ready, it can just be temporarily disabled. Even more, when a
feature is ready to ship, you no longer have to do a big bang roll out to
all users. Instead, you can gradually roll out and make a data-driven
decision on to roll out further or maybe even rollback! That dramatically
de-risks rolling out new features.
Finally, improvements to new features can be built side by the side of the
old feature and using A/B tests you can then decide which feature should
remain. This allows optimising user engagement in your app.
I believe this was sufficient to portray the idea behind feature flags. I
have worked on a prototype version [1] of the feature flags that leverages
pure OSGi specifications. Being an Eclipse committer, I see several
benefits of making such a project flourish under the supervision of the
developers working on Felix. As Felix community primarily focuses on OSGi,
this project would avail benefits from further development, maintenance and
adoption.
Currently, the project is licensed under the Apache 2.0 software license,
but it still uses my top-level domain in the bundles. If you think the
project would be valuable, I would love to make the bundle names compatible
with the Felix naming conventions.
I would really appreciate your opinion regarding this proposal for the
contribution.
Thanks and Regards,
Amit
[1] - https://github.com/amitjoy/feature-flags-for-osgi
--
--
Carsten Ziegeler
Adobe Research Switzerland
[email protected]
