-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support a trunk based development like Hyperion does with feature flags #534
Comments
Could you give some examples of what features you would like to enable/disable with flags like this? The example you have here is a particular endpoint. In |
I see the feature flags as a catch-all for maintaining trust but at the same time experimenting with new things. With feature flags we can selectively deploy various features. (The assumption here is that we keep features behind endpoints and they add to the features set of the system rather than change it. The latter would change only in major versions I guess?). Whether the feature flag is in the client or the server is an architecture question where I'd say that permissive client and restrictive server is the more natural way. Furthermore if blueapi has many clients (cli,jython and a GUI in the future) maintaining consistent feature flags across the 3 of the would be much more difficult compared to just in the server |
But if it's feature flags for endpoints we would need logic in the clients anyway to say whether they try and call the endpoints? Otherwise the clients will fail if they expect endpoints to exist that aren't there due to feature flags? It seems simpler that if features are new endpoints we just have expose those endpoints regardless then have flags in the clients about whether we want to use them or not? |
we could configure the endpoint to return a meaningful message: 'your server instance does support this feature' and the clients would render that gracefully without failing |
@callumforrester , @DiamondJoseph request for comments |
Makes sense to me, @DominicOram's view carries most weight as he's been using feature flags for a while now |
Can we please clarify what this issue is for exactly? The title is very vague. Is it actually "Add the ability to enable endpoints based on a feature flag from an |
title is not exhaustive, there is also description. the main idea is for the DX and trunk based development, as opposed to long-lived side branches. whether the feature flag is in an if we have an API accessible to any client then the feature flags in just one client don't protect from unsupported requests to the server, if it is not protected. from a DX perspective, I'd like to push a half-done endpoint on Friday with an I am aware that this is opinionated. |
Completely agree with this, but that's a process point in your team not an actionable thing that you can write a |
I moved the 'example implementation' for flag-guarded routes from a comment into the description |
I'm also satisfied that no code changes are needed for now, but am also interested in @keithralphs and @DiamondJoseph's opinions |
not needed anymore |
Would allow us a gradual rollout of features using env flags with a fine-grained control between beamlines, with all of them being potentially on the latest version of the main flow.
@DominicOram , @dperl-dls please send some pointers
main area this would see use is in the endpoints
example implementation
The text was updated successfully, but these errors were encountered: