Yeah, I'll make sure to listen to the podcast, but generally I'm on the side of feature flags.
On Wed, Mar 11, 2015 at 4:58 PM, Corey Floyd <[email protected]> wrote: > Yeah - after listening to the podcast I was on the fence about it too… I > think they bring up good points on the tradeoffs of both (even the hosts > were split on their preference at the end). > > I was initially attracted towards the git methodology as it gets these > business decisions out of the code base - but I also think that having > these flags that work at runtime (from a debug menu) is really valuable for > testing purposes. > > One thing I am not convinced on is that there will be "less work at the > end" when integrating features into a release with the feature flag > methodology - I feel like that could still be a problem if you are not > merging/rebasing. They discussed this in the podcast almost as an aside - > but it is entirely possible to develop conflicting features using feature > flags if developers do not coordinate (I feel this is really an orthogonal > issue to enabling features). > > Still - I think the feature flag solution has promise - but I am way more > interested in it if we do it as run time option to get the testing/QA > benefits. > > > On Wed, Mar 11, 2015 at 4:08 PM, Bernd Sitzmann <[email protected]> > wrote: > >> I have not listened to the podcast yet, but my opinion is similar to what >> Brian described. >> So, +1 for feature flags. >> >> Bernd >> >> On Wed, Mar 11, 2015 at 1:40 PM, Brian Gerstle <[email protected]> >> wrote: >> >>> Listened to it this morning, gotta say I think I'm on "Team Flag," if >>> it's done well. IMO we should try one (or both) and see how it goes. >>> Here's my take on each approach: >>> >>> Branches are cheap to implement, but come at the a potentially high cost >>> if you don't continually rebase and try to keep the work scope as small as >>> possible. At a previous job we used git submodules as pseudo feature >>> branches. There were common problems w/ dependencies between branches and >>> between branches and the main repo, which as the hosts mention are often >>> pushed later in the process. >>> >>> Flags are more expensive to implement up front, but allow for truly >>> continuous integration and delivery—as well as the potential for gradual >>> rollout. IMO it could also lead to better architected code since feature >>> flags require you to codify the boundaries between the "platform" and the >>> features (and between the features themselves). You also need to limit >>> global state and have good test coverage (which we should do anyway) in >>> order to keep undesired side-effects to a minimum. My previous job also >>> switched to this model and was able to improve their release cadence and >>> sync between features (IIRC, don't have any concrete evidence to back it up >>> unfortunately). >>> >>> >>> On Tue, Mar 10, 2015 at 11:16 PM, Corey Floyd <[email protected]> >>> wrote: >>> >>>> 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]> >>>>> 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]> >>>>>> 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]> >>>>>>> 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] >>>>>>> > https://lists.wikimedia.org/mailman/listinfo/mobile-l >>>>>>> > >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Mobile-l mailing list >>>>>>> [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] >>>>>> 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 >>>> >>>> >>> >>> >>> -- >>> EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle >>> IRC: bgerstle >>> >>> _______________________________________________ >>> Mobile-l mailing list >>> [email protected] >>> https://lists.wikimedia.org/mailman/listinfo/mobile-l >>> >>> >> > > _______________________________________________ > Mobile-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/mobile-l > >
_______________________________________________ Mobile-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/mobile-l
