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.
http://edgecasesshow.com/123-whats-the-deal-with-nsinteger.html (Topic is covered in the 2nd half of the show) On Monday, March 9, 2015, Dan Duvall <[email protected]> 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 <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> 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 <[email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');>> 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 <[email protected] >>> <javascript:_e(%7B%7D,'cvml','[email protected]');>> 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 >>> > [email protected] >>> <javascript:_e(%7B%7D,'cvml','[email protected]');> >>> > https://lists.wikimedia.org/mailman/listinfo/mobile-l >>> > >>> >>> _______________________________________________ >>> Mobile-l mailing list >>> [email protected] >>> <javascript:_e(%7B%7D,'cvml','[email protected]');> >>> https://lists.wikimedia.org/mailman/listinfo/mobile-l >>> >> >> >> >> -- >> Corey Floyd >> Software Engineer >> Mobile Apps / iOS >> Wikimedia Foundation >> >> _______________________________________________ >> Mobile-l mailing list >> [email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');> >> 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 [email protected] https://lists.wikimedia.org/mailman/listinfo/mobile-l
