At the Financial Times we were solving these sorts of problems with what we branded Origami components - see http://registry.origami.ft.com.
Disclaimer: I used to work on this. Each component was in it's own repository, releases were made on an ad-hoc basis - as and when needed, breaking and major changes would necessitate a major version change etc. Product and component developers - and there were a lot of them - would then pull in a component at build time (we even supported at runtime with https://build.origami.ft.com!) locked to a particular major version - we used semver religiously. Bower was used as a dependency manager - admittedly with varying degrees of success at first. As you can see, there are a lot of individual components in different repositories - we had only minor issues with this, but we solved a lot with tooling and process: http://origami.ft.com/docs/component-spec/modules/#managing-new-releases. Tooling when using web components, from our experience there, is *so* important - the 'Component Info' section and the data found there was particularly useful when managing releases and figuring out dependents and dependencies: http://registry.origami.ft.com/components/[email protected]#section-info for example. Tooling also helps with the discovery problem: registry.origami.ft.com - which becomes a kind of living style guide. This worked at scale - some background can be found here if you're interested: http://triblondon.github.io/talk-components-origami/#/1 I'm actually for a single repository of components, but *only* if we can make it easy for the community to pull in and use components in their apps as dependencies with minimum friction. Sam On Thu, Oct 29, 2015 at 6:20 PM, Augustin Trancart < [email protected]> wrote: > > On 29/10/2015 18:03, Fabrice Desré 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. >> > > My 2 cents: I'm far from advocating a unique repo, but having too many > repos with dependencies between them is not great either. > I personally found working on gaia-icons quite painful (as a reference: > bug 1209961 [1]. The number of PR it has is ... meaningful). It's difficult > to make contributor stick around if they need to update X repos before even > considering pushing their changes to gaia. > > So I would propose to have only one repo for all web components of gaia. > This way, it would be much easier to make change to a wc which other wc > depend on. And we could still tag stable versions and pull them gaia-side. > Things stay manageable, even if every app has an explicit dependency on > this shared repo. > > Another drawbacks I see of having a lot of separate repos for shared is > that their discovery is made more difficult. They risk becoming underused. > gaia-icons is a good example again: I don't know the whole story behind it, > but I guess the idea was to provide a set of common icons for FxOS. A lot > of apps have actually their own svg or png that luckily often look more or > less the same (I'm speaking about back, forward, send, edit-mode, close, > attach icons, and many others). > > TL;DR Basically, let's keep the dependency tree as flat and simple as > possible to avoid headache. > > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1209961) > > Augustin Trancart > Phoxygen > > > > > - 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 >>> <[email protected] <mailto:[email protected]>> 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 <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> >>>> >>>> On Wed, Oct 28, 2015 at 11:52 AM, Patryk Adamczyk >>>> <[email protected] <mailto:[email protected]>> 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 >>> [email protected] <mailto:[email protected]> >>> https://lists.mozilla.org/listinfo/dev-fxos >>> >>> >>> >>> >>> _______________________________________________ >>> dev-fxos mailing list >>> [email protected] >>> https://lists.mozilla.org/listinfo/dev-fxos >>> >>> >> > _______________________________________________ > dev-fxos mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-fxos >
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
