Create prod app for Bramble in parallel to prod Thimble

[humphd]

We want to do our switch from Thimble to Bramble in a staged way. This means shipping two apps to prod, and managing the default app users get via URL. At first (old) Thimble will be the default, with a link that lets people get to the (new) Bramble (it will also have a link to get back to the old). Google does this kind of thing a lot, with a long opt-in period for trying out a new version of an app before retiring the old.

I think what's involved here is the following (you'll have better understanding of the actual work involved, so let me know what I'm missing):

• create https://thimble-new.webmaker.org and https://thimble-classic.webmaker.org. Each need SSL.
• ship Bramble to https://thimble-new.webmaker.org on prod, and old Thimble to https://thimble-classic.webmaker.org
• setup https://thimble.webmaker.org to point at https://thimble-classic.webmaker.org for now
• later, we'll file another bug to switch that, such that https://thimble.webmaker.org points at https://thimble-new.webmaker.org

In an ideal world we'd do this to fit within our current heartbeat, which ends next Friday, May 22. I've got a bug in Thimble on this at https://github.com/mozilla/thimble.webmaker.org/issues/505

cc @sedge

[sedge]

@jbuck Choosing where the apps live touches on id.webmaker.org integration as well, since we'll need client ids/secrets for both apps.

[jbuck]

@humphd will old and new be sharing a database?

• [x] consider alternate names for "thimble-new". We'll call it "thimble-beta"
• [x] update webmaker.org SSL cert to include "thimble-classic" and "thimble-beta" subdomains
• [x] Deploy it to Heroku

[humphd]

RE: sharing a db, I'm not sure what to say. We're going to be evolving the whole publish flow to support multiple files, so might be best to separate them so we don't have a hard time with that. @sedge?

[JordanTheriault]

Name alternative thoughts: "thimble-evolved" "thimble-now"

As far as database, it may be necessary to migrate data from the old to the new once we shut down classic which could be a neg for separation. The question could be, can multi-file be added to the database structure which is more likely.

[sedge]

If we separate the DBs then we lose the majority of the opt-in's appeal, since I suspect users will want access to their previous makes.

I think we'll have to co-ordinate the multi-file back-end publishing with the way thimble handles projects so that projects with a single-file stay that way until old thimble is deprecated.

[sedge]

As a followup to @JordanTheriault 's point, the database will have to be migrated into a multi-file paradigm, but we'll have to distinguish between multi-file projects and single-file ones so each version of thimble operates correctly.

Once multi-file is enabled, backwards compatibility is pointless. Having said that, I'm worried that we'll miss out on valuable user testing if we don't allow forwards-compatibility. @humphd What do you think?

[humphd]

I'd keep this as simple as possible: we're only doing multiple apps so we don't break people as we harden the new stuff. If people don't have the same data in both apps, I'm not sure that's a huge deal, but migrations and conflicting schemas will be.

[humphd]

In other words, multiple apps is about access to a working version of Thimble for everyone vs data sharing between the apps.

[jbuck]

Requested a new SSL cert with "thimble-beta" and "thimble-classic" subdomains: https://bugzilla.mozilla.org/show_bug.cgi?id=1165452

[jbuck]

This is now live at https://thimble-beta.webmaker.org (might take up to 30 minutes to propagate)

[humphd]

Thanks, Jon.

[sedge]

+1