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
