University of Melbourne teacher candidate assessment platform
Multi-tenancy in practice: a single assessment, many institutions
Some software has to be the same everywhere and different everywhere at once. An assessment used in selecting candidates into teaching degrees is exactly that.
The instrument has to hold its shape wherever it runs, while each institution wants its own:
- branding
- cohort
- admission dates
- rules about how a candidate gets an account
Build it once and run an instance per institution per cycle: that is the obvious answer, and it is also where the work is. Every new instance starts life as a copy of a working one. A copy is only ever as safe as your ability to prove it still works.
Our part in the partnership: development, testing and maintenance from 2018
The Teacher Capability Assessment Tool is owned by the University of Melbourne and was built by Salsa Digital(Opens in a new tab/window), whose team carried the platform and its relationships with the institutions using it. We joined the engineering in 2018.
Our work ran across the running instances:
- software development on the application
- automated testing across the institution instances
- ongoing maintenance
A point worth saying plainly. The assessment instrument belongs to the institutions that use it; our work was the software it runs on.
A single PHP codebase, an instance per institution and per cycle
Candidates registered, confirmed who they were, and worked through a set of structured modules at their own pace. Staff worked over the cohort through an administrative dashboard, and results left the system as PDF reports. Each institution and each intake had its own instance, all running from the same codebase.
None of this was Drupal(Opens in a new tab/window). It is a classic PHP application on Zend Framework 1:
- jQuery and Bootstrap on the front end
- a grid component for the administrative tables
- a PDF library for the reports
Most of our work is Drupal, but the engineering underneath any long-lived platform is the same: a real domain model, a test suite that means something, and a repeatable path to production.
Making a copy safe to ship: end-to-end Behat testing per instance
The testing is the most interesting engineering on the project, because it takes the multi-tenancy problem head on. Every institution instance had its own end-to-end profile with its own base URL and matching tag filter, and a single script ran them all together.
2 details are worth borrowing. Registration issued a temporary password by email, so an end-to-end test could not get through the front door without reading it. The suite ran against a real mail catcher and took the password out of the message, exactly the way a candidate would.
Some institutions provisioned their candidates directly rather than letting them register themselves. Rather than skip those instances or test a path they had deliberately closed, we re-used a real account and reset its progress between runs, behind a single flag.
When something did break, the suite saved a screenshot at that moment, through our open-source Behat screenshot extension(Opens in a new tab/window), so a failing run explained itself instead of just going red.
All of it served a single purpose: every new instance was a copy of a working one, and the end-to-end suite is what made copying safe. For a client, that reads as confidence: each admission cycle starts from an instance the suite has already checked.
Atomic releases onto the university's own infrastructure
The platform ran on the University of Melbourne's own infrastructure, so releases followed the university's process rather than ours. That made the release path a documented, hand-run sequence:
- build the artefact
- send it up to the server
- unpack it beside the running application
- swap the directories in a single move, leaving the previous release exactly where it stood
That last part is the whole trick. The cutover is a single move rather than a file-by-file copy, and the rollback is the same move in reverse. When a client's platform team owns the servers, a release procedure that fits their process and stays safe beats one that fits ours.
What it adds up to: multiple institutions, multiple cycles
The platform ran for multiple institutions across multiple admission cycles. Instances ran for other universities, for state education departments and for Catholic education authorities, each with its own cohort and intake dates.
A single codebase, several unrelated organisations, and a fresh instance for every admission cycle.
That is the outcome worth naming. Several unrelated organisations ran the same software on their own terms, and each year's instance could be stood up with confidence rather than crossed fingers. For a client, that is what a well-drawn platform buys: the next institution is a setup exercise, not a new build.
For platforms that several organisations have to run
Everything on this page is 2 of our services running on one long-lived platform: software development on an application several organisations depend on, and support and maintenance across every running instance.
If you run an assessment or admissions platform that several institutions share, or a custom application that has outlived the team who built it, this is the shape the engagement takes: an end-to-end suite that checks each instance before it ships, a release path that fits your own platform team's process, and engineers who work on the stack you already have. The same engineering is available with AI-assisted delivery where it suits the work, at the same tested standard.
If your next admission cycle depends on standing up another instance of a platform nobody has tested in a while, tell us what it runs on.