I did a talk on Monday about how /why we are using Web Components in Firefox OS.
Video: https://air.mozilla.org/london-web-components-meetup-wilson-page-web-components-in-firefox-os-20151026/ Slides: http://wilsonpage.github.io/presentations/web-components-in-production/ *W I L S O N P A G E* Front-end Developer Firefox OS (Gaia) London Office Twitter: @wilsonpage IRC: wilsonpage On Thu, Oct 29, 2015 at 5:14 PM, Naoki Hirata <nhir...@mozilla.com> wrote: > 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 > >
_______________________________________________ dev-fxos mailing list dev-fxos@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-fxos
