As well as continually improving the actual system, we also make continuous improvements to our hosting and deployment infrastructure. Well, I say “actual system”, but of course the point is, to you, it’s all of a piece. The code and the web servers and database servers might all be separate things to me, but if you’re a user of the system, the only thing you care about is: “is it working?”
Our previous deployment procedure amounted to:
- I make a build.
- As long as passes basic smoke tests and we haven’t touched anything that we expect to cause problems, I stay up till 3am and put it live.
This was adequate, because by releasing frequently we limited the scope for show stopping bugs. Development methodologies that involve developers going away to work on branches for months at a time and releasing loads of features at once can cause massive headaches on upgrade. Staying “close” to the live code cuts down the opportunity for nasty surprises.
Really, there were two problems with the previous system:
- I had to stay up till 3am.
- I could upgrade 1 site, all the live sites, all the test sites, or all the sites, but nothing much in between.
So over the last couple of weeks we’ve added some extra control to our existing deployment scripts.
Now:
Every instance (that is, customer live site or customer test site) in the management database has a “target version”. This can be an actual version number, or a special value of “alpha”, “beta”, “release”, “stable”. Every instance also has a current version. Overnight, the target version is resolved and checked against the current version, and if they are different, and upgrade is triggered to the target version.
I expect most customer live sites will be set to “release” and most test sites to “beta”. If, in order to fix a particular bug, a customer needs an update early, I might target them at a particular version, rather than “release”, and then they’ll get that version without needing the whole version to be marked as release.
Some sites might want a slower pace of upgrades: these we’ll mark as “stable”, and only mark a build as “stable” after it has been “release” for 2 weeks with no known problems.
TLDR: Upgrades will happen automatically overnight when a version is flagged as release quality. If you want fewer upgrade, we can set you to “stable”.