We thought we’d take a few minutes to help explain the development process we use for Three Rings.
Three Rings typically receives three major updates per year. We call these Milestones, and we tend to organise them so that they take place around Christmas, around Easter, and in about September. Traditionally, these times were chosen because they coincided with the beginnings of University terms (at that time, the vast majority of Three Rings users were University Nightlines), and so by timing our releases strategically, we could minimise the disruption caused to our users. Nowadays we keep those release times because they’re pretty much equidistant throughout the year, and it suits us to develop on a four-month cycle.
Our current convention for naming milestones is based on the chemical elements and their isotopes, in an alphabetical order, so we’ve had Milestones Aluminium, Boron, Copper, Deuterium, Erbium, Fermium, and our current Milestone, Gallium (prior to these, we had a more mundane and boring policy of naming Milestones after the core features that they added).
The cycle looks like this:
Development
Most of our time is spent in the box at the top of the cycle – development. This is when we’re writing code to implement the new features that are due to be deployed at the next upcoming Milestone. As far as possible, we implement a policy of test-driven development: this means that first, we write a computerised test that, when a feature is completed, will “pass”, but right now, it “fails”. We then write the program code that makes that feature work, so that the test passes. We also run all of the other tests we’ve ever written so we know that the new code we’ve just written won’t have any unwanted knock-on effects on any other parts of the system. We’re able to do this because we write the tests in a way that allows them to be automated: we can click a button, and our test suite will go off and it will try to do everything that it is possible to do in Three Rings, and it’ll report back to us if anything didn’t work as expected.
This belt-and-braces approach minimises the risk that any bugs can creep into the code. And if a bug does somehow slip through because a test wasn’t as complete as it could be, we can extend that test so that it will pick up on that particular issue in future, to help ensure that it can’t happen again.
Testing
For two weeks prior to the actual release of a new Milestone of Three Rings, we launch a special version of it to our test team. These volunteers – who are all current or former volunteers at organisations that use Three Rings – dedicate their time during these two weeks into testing all of the new features (and many of the old ones) to ensure that everything works like it should. If they find any problems, we take those bits back into the development process and fix them, then put them back onto the test system so that our testers can have a chance to break them again.
Some of our testers are particularly thorough, and will try to do things with Three Rings that we never even thought of, and thanks to them we’re able to find sneaky little bugs without exposing regular users to them. Often these bugs are related to things just not “looking right” on particular kinds of computers or when using particular web browsers: it’s really valuable to have such a large team of people, all with different computer systems and different ways of working, trying out each new release of Three Rings.
(the test team’s always in need of new volunteers, by the way – if you’re interested in volunteering, get in touch)
Deployment
It’s always exciting when the big day comes for a new Milestone of Three Rings to be deployed. Earlier in the day, we always do a “dry run” of the deployment, checking that all of the new data that has been added by volunteers since the testing period started is going to work perfectly with the new release, before we put the new code on the server. Then, at around midnight (so as not to disrupt organisations who might be using the system any more than is necessary, we schedule deployments for “quiet times”), we “turn off” the site: volunteers using the site at this time will just see a page apologising for the inconvenience and asking them to check back later.
We always schedule an hour or two’s potential downtime in which to deploy the new version, although in practice, it always takes a lot less time than that (the Milestone: Erbium release took a record 12 minutes). Once we’re sure that the deployment has been completed successfully, we enable access to the server again.
In recent years, we’ve attracted a hard-core following of volunteers who, it seems, will wait up until the small hours of the morning to try to be the first people at their organisation to try out the new version. Sometimes we’ll get e-mails from these people to say “congratulations” or “thanks for the new release”, which can be a real pick-me-up after a late night’s work and a real pick-me-up for the tired volunteers of the Three Rings team!
Planning
Shortly after the deployment, the Three Rings team gets together and sits down to discuss what features are going to make it into the next Milestone. There are some tough decisions to be made, because there’s only so much time and there’s always so much that we’d like to do. We have a procedure for deciding which features are to be developed next, based on the number of organisations that they will help, how difficult it is to implement, how flexible the new feature could be made to be relevant to different organisations, and so on: we’ll try to write another article on a later date to describe the process.
After this, we begin development again! Sometimes – rarely – a bug or two will be found in the “live” system, and we’ll have to write a fix (which then has to be tested and peer-reviewed in the live branch, before it can be deployed to the live server, and it has to be merged into the current development process), but for the most part, the Three Rings server “runs itself”, needing only minimal intervention by the Three Rings team: which allows us to spend as much time as possible on working on new features and supporting our users.