Feature flags would help, but they also add an extra development investment to make sure all features are engineered in a way that a flag can shut them off without other bad things happening (not necessarily a bad thing, but require more effort).
Another route to go is to manage this in git using the branches. There are several methodologies for this, and your branching strategy will depend mostly on how the team wants to operate. Pretty much all of them boil down to NOT merging features into master that are not going to be deployed after the current sprint.
On Mon, Mar 9, 2015 at 5:19 PM, Tomasz Finc tfinc@wikimedia.org wrote:
Excited to see this. In order for this to be successful we'll want to developer a health dashboard for the app and set alarming for it whenever we dip above/below certain thresholds. One of the challenges that you face when releasing often is that the amount of attention you keep during small iterative releases. It's easy to keep very focused for 2-3 releases but after that attention can drift to just the major releases. And while it's great to read reviews and find out a subjective metric of how we're doing we need to get in front of it with objective metrics.
Thus having an app health dashboard showcasing: search, readership, editing, etc can easily show you if you've had any regressions. These would not only be useful for small bug fix releases but would also help validate our major product releases.
I'll leave it with you guys to define what metrics are necessary to define a healthy app.
--tomasz
On Mon, Mar 9, 2015 at 1:31 PM, Dan Garry dgarry@wikimedia.org wrote:
Hi everyone,
There is a long time between production release on Android. The reason
for
this is because we have featured merged into master that are sound from
an
engineering standpoint, but aren't quite ready for release yet. These features often block production releases.
As product owner, pushing out regular bug fix builds would make me very happy! But there is a requirement that we are able to not push out
features
that are merged but not ready for production yet. This can probably me managed by feature flags.
Dan Duvall (on cc) from Release Engineering will consult to help Dmitry
and
Bernd figure out what their process should be for maximum effectiveness.
Thanks!
Dan
-- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l