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
> <[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
>
--
Fabrice Desré
b2g team
Mozilla Corporation
_______________________________________________
dev-fxos mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-fxos
