Does feature flags have a place in SilverStripe?

[stojg]

Hi y'all,

I've been thinking about feature flags for a while and wonder if they would make sense in SilverStripe land?

In short, having the possibility to turn sections / features of a site on and off. A couple of use cases:

 - Turn off a feature because it turned out to be buggy and it's quicker to turn a feature off then redeploying a older version

 - Only enable a feature for a subset of the users to ensure that it works correctly

 - During high load turning of features that causes high load.

Another question, how would this be implemented in a SS?

Thanks,

Stig

[Fred Condo]

Regarding only your first use case, it should not be slow to roll back a deployment if you are using something like [Capistrano][1] or [Magallanes][2] for deployment.


[1]: http://capistranorb.com
[2]: http://magephp.com

[James Turner]

Sounds interesting! I can't see it being terribly useful for every site but for the bigger sites, I think it could be quite powerful.

If the framework and CMS followed a specific standard for doing flags, a default install had only stable features enabled and you just need to do a config update to turn on/off an interface to change it (or do all the flags via YAML config).

I do like the idea of being able to give specific subset of users some functionality, sounds similar to what Facebook does when rolling out changes. I have read they can control the update to fine grain details like everyone in country X that is Y years old with more than Z friends. I think it could be difficult getting that level of control in SS with every site acting differently but it would be worth looking into further in my opinion.

[Ingo Schommer]

Do you have an example of a core feature this might be applicable to, and that can’t already be solved through permissions and/or the YAML config? I guess there’s nothing stopping you from using feature flags in custom code however you choose (environment constants, YAML config, …), right? 

In terms of using feature flags to avoid merges and feature branches in core, I think flags work better for controlled closed-source deployments like flickr, but not so well for open source releases. Basically, either a feature is ready for a release, or it should be in a feature branch or master where developers can get a preview by using git.

If there’s a valid use case for core, I’d want to ensure that we include a standardized way to dump environment+config when ever bugs are reported, otherwise core devs will chase their tails trying to figure out bugs, just to find out that the bug reporter has turned on some feature flag with side effects ;)

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at http://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.

[Zauberfisch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I find the idea intriguing, but am generally on ingo's side here,
the way our development workflow works now (as far as I understand),
it would in time probably become a bigger mess than having to deal
with branches.

but then again, I actually like how browsers handle new features now,
they kind of run the same trick with hiding features that are already
in the software from end users while still giving spec authors and
developers a way to use/play with/test them.

so perhaps we can find a valid use-case where it would make sense to
be able to give some people a preview of it.
but in general I would probably vote against using feature flags for
features that are still in development.

On 2014-07-09 07:43, Ingo Schommer wrote:
> Do you have an example of a core feature this might be applicable
> to, and that can’t already be solved through permissions and/or the
> YAML config? I guess there’s nothing stopping you from using
> feature flags in custom code however you choose (environment
> constants, YAML config, …), right?
>
> In terms of using feature flags to avoid merges and feature
> branches in core, I think flags work better for controlled
> closed-source deployments like flickr, but not so well for open
> source releases. Basically, either a feature is ready for a
> release, or it should be in a feature branch or master where
> developers can get a preview by using git.
>
> If there’s a valid use case for core, I’d want to ensure that we
> include a standardized way to dump environment+config when ever
> bugs are reported, otherwise core devs will chase their tails
> trying to figure out bugs, just to find out that the bug reporter
> has turned on some feature flag with side effects ;)
>
> On 8/07/2014, at 9:48 pm, stojg <stojg.l...@gmail.com

> <mailto:stojg.l...@gmail.com>> wrote:
>
>> Hi y'all,
>>
>> I've been thinking about feature flags

>> <http://code.flickr.net/2009/12/02/flipping-out/> for a while

>> and wonder if they would make sense in SilverStripe land?
>>
>> In short, having the possibility to turn sections / features of a
>> site on and off. A couple of use cases:
>>
>> - Turn off a feature because it turned out to be buggy and it's
>> quicker to turn a feature off then redeploying a older version -
>> Only enable a feature for a subset of the users to ensure that
>> it works correctly - During high load turning of features that
>> causes high load.
>>
>> Another question, how would this be implemented in a SS?
>>
>> Thanks, Stig
>>
>> -- You received this message because you are subscribed to the
>> Google Groups "SilverStripe Core Development" group. To
>> unsubscribe from this group and stop receiving emails from it,
>> send an email to silverstripe-d...@googlegroups.com

>> <mailto:silverstripe-d...@googlegroups.com>. To post

>> to this group, send email to silverst...@googlegroups.com

>> <mailto:silverst...@googlegroups.com>. Visit this group at

>> http://groups.google.com/group/silverstripe-dev. For more
>> options, visit https://groups.google.com/d/optout.
>

> -- You received this message because you are subscribed to the
> Google Groups "SilverStripe Core Development" group. To unsubscribe
> from this group and stop receiving emails from it, send an email to
> silverstripe-d...@googlegroups.com

> <mailto:silverstripe-d...@googlegroups.com>. To post to

> this group, send email to silverst...@googlegroups.com

> <mailto:silverst...@googlegroups.com>. Visit this group at

> http://groups.google.com/group/silverstripe-dev. For more options,
> visit https://groups.google.com/d/optout.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTvSKqAAoJEMSsa3tQrLVgjcYH/096u8szSHbx28vEd50xYbKq
/5SLSgfkVFDe+ya0IrUpvZL+WCotrnhmvA4J+/cnPW07Lnv71hKBgbnyCeCfuZfb
HpPv80UUjxF18hv13KDSxTEH8ujHigcIr+gISTBKOMdhLCihUfpVUTllnlNn5MeW
/AgG+FdFl1GyHh+fJ7flRkFiS6ayNtMaan/seRz0VhcpZkxgU2AO5KMMCjuPP0TM
FzDspv30SYhrFFBMxYAFkACHiGai5zp7cBbroAQi5PDw/KkV+DUa1wDPLmvt4MB7
KDwdsAWLjki0IQT1CHQ7AxtuACWmmeY+8GMUsU/wUX0FEkHgVI3F9hn5lqz7EI4=
=4ERN
-----END PGP SIGNATURE-----

[Zauberfisch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

another thought that just occurred to me after sending the last message:

I think we should focus on making the features we have more
configurable and/or more modular.
And in that way provide the ability to enable/disable (configuration
of core features) or add/remove (modules).
This will make a "feature flag" obsolete, or perhaps can be considered
a feature flag.

One thing we could do is build some form of a convention of what
things of a feature or module should be configured, and how the
configure syntax should look like.

On 2014-07-09 11:08, Zauberfisch wrote:
> I find the idea intriguing, but am generally on ingo's side here,
> the way our development workflow works now (as far as I
> understand), it would in time probably become a bigger mess than
> having to deal with branches.
>
> but then again, I actually like how browsers handle new features
> now, they kind of run the same trick with hiding features that are
> already in the software from end users while still giving spec
> authors and developers a way to use/play with/test them.
>
> so perhaps we can find a valid use-case where it would make sense
> to be able to give some people a preview of it. but in general I
> would probably vote against using feature flags for features that
> are still in development.
>
>
> On 2014-07-09 07:43, Ingo Schommer wrote:
>> Do you have an example of a core feature this might be
>> applicable to, and that can't already be solved through
>> permissions and/or the YAML config? I guess there's nothing
>> stopping you from using feature flags in custom code however you

>> choose (environment constants, YAML config, ...), right?

iQEcBAEBAgAGBQJTvSORAAoJEMSsa3tQrLVgdLwH/jEhNW8/QSvEU1m+2YmVVQQX
yZvfk5Yfw74Cnz79fonED9pGXmcE7VlYW1VvRMZ7AMZ0WtPBZ0I1Amd/cHxAPa9s
jH9wzx6+Vh6ANZqnoF2juwBE49IjdkCwDnT50GTXBkc72EL1dc4SPVBkA/3/yKAb
r2gPWKBr+RL2/1wrkRQLUbsy1mCsXAhIS5NDoJmLicY1tyl8zFKL25jqBf/HttX1
Gt4qzV0W3WfHtgwDIQ5MGgtbf7VwJ4HoAFXsQ2H4swhZo/O6FKwXPPOFIoB3uQv2
EzI1g6UIhZJrVCKIUG0fj+Z1O/AullsR2lJ5YQb7HiqNmVylNCd2KMDKzQv968o=
=8vzO
-----END PGP SIGNATURE-----

[Sigurd Magnusson]

Re "I would probably vote against using feature flags for features that are still in development."

Flags are a concept used intentionally during development in the continuous delivery/integration paradigm, to avoid merge/branching hell, and the benefits have outweighed the costs/drawbacks in some significant software projects; refer http://www.amazon.com/gp/product/0321601912.

Sig 

To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.

[Mateusz Uzdowski]

I like flags. But the mechanism should not be entombed in the config system - that's developers domain, kept in VC, and overwritten on deployments. Flags should be outside of the webroot, easily accessible by ops, settable via puppet, bash or other automation, and ideally wouldn't require a flush nor a restart (I don't really want to do a flush if I'm trying to disable a feature because a server is under high load).

I ended up using defines in _ss_environment.php which is currently the only standard way of describing the environment to SS. I didn't really like it because the file is hard to maintain via puppet. I think I'd prefer a Linux approach: _ss_environment directory with a key-value *.conf files that are all automatically pulled in. This way I could have an arbitrary amount of conf files - and as ops I could easily add a new file with temporary changes.

I'm not sure if anything as elaborate as the config system is necessary here...

m

[James Turner]

I agree it should not be in the config system however I think it should be controllable via the CMS. One of the reasons this would be useful is if an administrator can turn it on or off, not just someone with direct file access and knowledge of how to update the config. So while the data could be stored in a folder called "_ss_environment" like you suggest Mateusz, I really think the controls for this belongs in the CMS.

[stojg]

I ended up using defines in _ss_environment.php which is currently the only standard way of describing the environment to SS. I didn't really like it because the file is hard to maintain via puppet. I think I'd prefer a Linux approach: _ss_environment directory with a key-value *.conf files that are all automatically pulled in. This way I could have an arbitrary amount of conf files - and as ops I could easily add a new file with temporary changes.

I think that using environment variables in unix environment is the way to go. For example in apache you can set ENV variable that is passed to the php process.. I've tested with having a _ss_env that sets values like this:

define("SS_DATABASE_HOST", env("DATABASE_FROM_VHOST_OR_SYSTEM"));

I got the idea after testing heroku and other PASS, but as long as it's following these guidelines it's sweet http://12factor.net/config ;)

[stojg]

I gave it some though and realised that I would probably to a small module for this if I was working for a bigger site for a longer period of time, especially if I got get approval for continuos delivery. It's simple enough to implement as a DataObject with a section in the site wide config.

But does it have a purpose in core? No I don't think so.