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