As luck would have it, a very good tech podcast I
subscribe to recently
discussed this subject. It is a pretty good listen and discusses trade offs
for both feature flags and branching.
(Topic is covered in the 2nd half of the show)
On Monday, March 9, 2015, Dan Duvall <dduvall(a)wikimedia.org> wrote:
One very simple model that I think works well
with distributed software
(and should play somewhat nice with Gerrit) is to branch per minor release
(assuming somewhat semantic versioning). In this model, master can continue
to serve as an integration branch, bug fixes are developed against the
release branch and merged following each patch release, and features are
developed against master per usual. With Gerrit in the mix, you're
essentially left with a two-stage merge for bug fixes which can be a bit of
extra work to get them merged into master, but at least the pipeline is
greased for getting them released.
I can't say whether this would fit your team's workflow and, as Corey
mentioned, there are many different branching models to consider, each with
its own focus and drawbacks.[1][2] The one I've outlined above is geared
more for stability and maintenance but can probably be tweaked for more
frequent releases of features as well. I'm happy to brainstorm further.
[1]
http://blog.codinghorror.com/software-branching-and-parallel-universes/
[2]
https://msdn.microsoft.com/en-us/library/bb668955.aspx
On Mon, Mar 9, 2015 at 2:30 PM, Corey Floyd <cfloyd(a)wikimedia.org> wrote:
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(a)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(a)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(a)lists.wikimedia.org
>
https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
_______________________________________________
Mobile-l mailing list
Mobile-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l
--
Corey Floyd
Software Engineer
Mobile Apps / iOS
Wikimedia Foundation
_______________________________________________
Mobile-l mailing list
Mobile-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l
--
Dan Duvall
Automation Engineer
Wikimedia Foundation <http://wikimediafoundation.org>
--
Corey Floyd
Software Engineer
Mobile Apps / iOS
Wikimedia Foundation
_______________________________________________
Mobile-l mailing list
Mobile-l(a)lists.wikimedia.org