Beta Releases and how we deploy them: roll out plan for "bye bye spree" and "rails 4.1 upgrade"

Product Development
1

In this post I try to describe a generic process for releasing versions that come with big changes and higher risk of introducing serious issues in production.

The 2 projects at hand
The last bit of the bye bye spree project is currently in Test Ready: Bye bye spree - final PR 🎉 by luisramos0 · Pull Request #5978 · openfoodfoundation/openfoodnetwork · GitHub

After this is merged and released we will be able to integrate all the work already done for the rails 4.1. upgrade, review it, test it and merge it.

Bye bye spree will have to be merged/released in one step and then rails upgrade will be done afterwards, I’d say we will need at least two weeks between the two deliveries.

These will be two risky versions.

Both deliveries come with a risk. To mitigate that risk we can have phased releases. We release first to a small number of instances and then we make it a public version deployable to all instances. We can achieve this by using the term beta on the version number so that all instances will clearly know the version is not yet fully verified.

I am suggesting we release both bye bye spree and rails upgrades under beta versions (these 2 versions will be at different times a few weeks apart). For each of these beta versions we could nominate a “big instance” (UK, FR, AU) and a “small instance” (ES, BE, US) for the first deploy. After deploying to these 2 instances and the stable operation of the instances for a period of 2 weeks, we would deploy the release to all the instances (after two weeks we can publish a new non-beta release for the roll out with all in the beta plus extra/new updates).

Example release dates
week 44 - normal release v3.3.x - deployed to all servers
week 45 - beta release v3.4.0-beta with “bye bye spree” - deployed to FR and BE only (other instances run on v3.3.x)
week 46 - beta release v3.4.1-beta with latest updates - deployed to FR and BE only (other instances run on v3.3.x)
week 47 - normal release v3.4.2 with with latest updates - deployed to all instances
week 48 - beta release v3.5.0-beta with “rails 4.1 upgrade” - deployed to UK and US only (other instances run on v3.4.2)
week 49 - beta release v3.5.1-beta with latest updates - deployed to UK and US only (other instances run on v3.4.2)
week 50 - normal release v3.5.2 with latest updates - deployed to UK and US only (other instances run on v3.4.2)

An alternative scenario, if rails upgrade is for example ready on week 46, we decide what to do, we can wait for the end of the current beta before we start another one (by holding the merge of rails 4.1 branch and following the process listed above) OR we can add it to the beta release and start a new beta process of two weeks (for example, week 47, v3.4.2-beta with rails upgrade deployed to same FR and BE, and then wait 2 weeks to publish a non-beta).
The advantage of separating both betas is that all instances stay less time without updates.

Feedback is appreciated. I am also open to do something completely different :+1:

1 Like
2

I have no clue in what category this post should be (this is not tech specific), please change if you have a better idea about that :slight_smile:
image

3

The more I’ve thought about network - I concur its not a ‘feature’. It seems to me that ‘tools to build food networks’ is a core part of our product vision - maybe THE primary vision. Which makes me think, that maybe, when we get to our product vision, we should discuss this.

4

Hello Theresa, I may be missing your point or maybe you wanted to comment on another thread?

5

@luisramos0 thank you for this proposal. I think it is a good compromise because it allows a (hopefully) shorter time during which some instances don’t get updates.

I’m ok for FR to be the first instance to get bye bye spree.

For both bye bye spree & rails upgrade : where can I see the list of changes that I will need to follow closely?

Also, how well can we rollback? If we can rollback easily I even think roll-out are not needed, but that’s maybe a strong position :grin:

6

strange - I thought I did (comment in another thread) But I had some discourse weird things going on the other day. Ignore it. Sorry.

7

Thanks!!!

There’s nothing specific about them, it’s all technical for rails upgrade and all-inclusive for bye bye spree: rails upgrade changes very tech specific things, bye bye spree mvoes a lot of code around in all parts of the app but aims at changing nothing functionally.

ah, I completely forgot about rollbacks! I think you may be right :blush: that would mean none fo this is needed.
You know what we can do very easily: test the rollback in staging!