I'd like to point that their QA is their dogfooders (which we have to coerce people to do because of variety of reasons) and devs are proactive on making sure that they don't break and if they do, they end up having to fix it.
The context is a bit more different of an app versus an OS. If you make a patch to break an app, it's not as serious as if you make a patch to brick a device. I'm curious how many branches they have. On Thu, Oct 29, 2015 at 10:03 AM, Fabrice Desré <fabr...@mozilla.com> wrote: > It's interesting that you use Facebook as an example. There was a talk > recently from one of their release manager > (https://air.mozilla.org/release-engineering-at-facebook/) and some take > away are: > - they use a (huge) mercurial monorepo (like Google does). Everything > needs to always work on tip basically. For sure being a closed > organisation may make that easier, but FxOS/gaia could be seen as a > closed organisation with not much harm I think. > - no manual QA, everything relies on CI. They ship their sites twice a > day, their mobile apps weekly. > - all employees are forced to use the beta version. So when they stage > changes to users, it's not for quality/bug testing reasons but mostly to > test product ideas (ie. a/b testing). > - our build & CI systems are from the last glaciation compared to theirs. > > Fabrice > > On 10/29/2015 05:05 AM, Wilson Page wrote: > > Instantly propagating updates can sound dreamy, but live code everywhere > > can lead to regressions coming from nowhere. > > > > This approach also puts a massive burden on component reviewers and > > contributors. It's much safer to land changes to a component and have > > apps *PULL* in the changes. This gives the app owner a chance to spot > > regressions, file a bug, remain on the old version and avoid breakage. > > > > If component updates are *PUSHED *into the apps, regressions will > > increase. It is not possible for a component owner or contributor to > > know every single instance whereby their component is being used. > > Regressions *will* be caused by new patches, our job is to catch them as > > early as possible and mitigate the impact these regressions have. > > > > This problem is why the Semver <http://semver.org/> standard exists and > > package managers like NPM have grown so successful. > > > > *Our options are: > > * > > A. We force *PUSH* updates into apps and speed up the update process and > > introduce more global regressions. > > B. We land frequent risk-free incremental patches into a component's > > source repo and *PULL* stable versions into Gaia one app at a time (not > > to dissimilar from our train-model). > > > > *How do other people do it?* > > > > If we look at deployment strategies that have proven to work in > > production, they all tend look similar to Option B. Facebook doesn't > > push new features onto all of their users at once; they trickle the > > changes out to 1%, 2%, 3% of users, until it reaches 100% of users. > > > > This gives Facebook the opportunity to catch issues early, backout and > > fix; without impacting very many users. It would be appealing for them > > to be able to ship new changes to everyone in a split second, but this > > can hurt their users and end up costing more time than it saves. > > > > --- > > > > This clearly need some more discussion, but it's important to note *this > > is not a new problem* :) > > > > *W I L S O N P A G E* > > > > Front-end Developer > > Firefox OS (Gaia) > > London Office > > > > Twitter: @wilsonpage > > IRC: wilsonpage > > > > On Wed, Oct 28, 2015 at 8:56 PM, Justin D'Arcangelo > > <jdarcang...@mozilla.com <mailto:jdarcang...@mozilla.com>> wrote: > > > > I agree with Sam. But it needs to be trivial for apps to pick up the > > latest changes too. This could be easily solved with Bower. Each app > > could “lock in” to particular versions of the components they’re > > using. Then to get latest, the apps only need to have their version > > numbers bumped in bower.json. > > > > -Justin > > > > > >> On Oct 28, 2015, at 4:49 PM, Sam Foster <sfos...@mozilla.com > >> <mailto:sfos...@mozilla.com>> wrote: > >> > >> > >> > >> On Wed, Oct 28, 2015 at 11:52 AM, Patryk Adamczyk > >> <padamc...@mozilla.com <mailto:padamc...@mozilla.com>> wrote: > >> > >> > >> So there is also another part to this, and that would to have > >> it sit in a live styleguide. > >> Imagine if the components can be in github and a single change > >> in github would instantly update: > >> + master and every FXOS app > >> + style guide website > >> > >> That would be amazing! > >> > >> It would really echo the ideas of focus and dynamic efficiency. > >> > >> > >> I don't think this is either practical or desirable. To have a > >> single change cause ripples across all FxOS apps would be really > >> really difficult to manage. Talk about strange magic from a > >> distance! Plus we are moving away from a monolithic "Gaia app". *I > >> do agree we need a simple opt-in way to buy into consistent look > >> and feel and control interactions*. And a way to pick up bug fixes > >> or updates from shared components without simultaneously breaking > >> unrelated stuff - see Jim's note about font-size changes. But I > >> would like to steer us away from the notion of a one-size-fits-all > >> UI toolkit. It always ends in tears. Apologies if I'm over > >> simplifying or mis-characterizing here, I just want to offer the > >> counter-argument. > >> > >> /Sam > > > > > > _______________________________________________ > > dev-fxos mailing list > > dev-fxos@lists.mozilla.org <mailto:dev-fxos@lists.mozilla.org> > > https://lists.mozilla.org/listinfo/dev-fxos > > > > > > > > > > _______________________________________________ > > dev-fxos mailing list > > dev-fxos@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-fxos > > > > > -- > Fabrice Desré > b2g team > Mozilla Corporation > _______________________________________________ > dev-fxos mailing list > dev-fxos@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-fxos >
_______________________________________________ dev-fxos mailing list dev-fxos@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-fxos
