JavaScript

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.

Government is organised by department. People are not: the case for one shared web platform

When you need something from government, you rarely know which department owns it. You know what you need: a permit, a payment, advice after a storm.

Yet a lot of government websites are still laid out the way the organisation is, because that is how digital tends to grow. One department at a time, each with its own site, its own supplier and its own way of publishing.

Victoria set out to change that. The Single Digital Presence programme aimed to bring 50 government websites onto one platform with one publishing standard, working to a principle that is still the clearest sentence we know on the subject: content belongs to the people who need it, not to the department that happens to own it.

What we built: the API layer, the multi-site engine and the testing architecture

Single Digital Presence is open source, and the record of who built what is public with it. Starting in 2017, we created most of the repositories behind the platform's Drupal(Opens in a new tab/window) layer, including its API layer, its multi-site engine and its testing architecture.

The pattern was the same across all of them. We laid the foundations before any feature work:

• the project scaffolding every repository is built from
• the continuous integration that runs on each change
• the automated tests over the behaviour that matters
• the developer workflow the teams work in day to day

The department's own team and its delivery partners then filled that structure with features. For a client, that order reads as a head start: whoever arrives next inherits a working pipeline instead of building one. The programme's technical lead credited the distribution and its testing approach from a conference stage in 2019.

In 2019 the Department of Premier and Cabinet contracted us directly, off the Victorian Government eServices Register, to write the developer documentation for the platform: how to work with the code, test an API endpoint and release a module. It shipped as a documentation site with a build that refuses to deploy if an internal link is broken.

One Drupal content system, many public websites: decoupled publishing with real preview

The heart of the platform is one Drupal content system serving many separate public websites, each with its own domain, brand, menus and homepage, all edited by agency staff in the same place. There is no separate installation per site.

A site is a piece of structured content, which makes bringing another agency on board a content decision, not a rebuild. For an agency joining later, that reads as a shorter path to launch: your site is configured on a platform that already runs, rather than procured and built again.

The public websites are rendered by a JavaScript front end, so Drupal serves content rather than pages. That split is good for performance and reuse, and it raises the question every organisation asks about decoupled publishing: how do editors preview their work when the content system renders nothing?

The platform's answer is one of the neatest we have seen, and it was not ours. The editor clicks Preview and lands on the real front end, which renders the unpublished draft exactly as the public will see it. We have carried that technique with us ever since.

Keeping a platform honest as it grows: shared testing across many repositories

The platform's Drupal code lives in many small repositories, each tested on its own. That is good for release safety and hard on consistency: every repository needs its own development environment, test harness and build pipeline, and copies of the same setup drift apart the moment nobody is watching.

We answered it in 2 pieces. The first was a shared test module giving every repository a neutral content type to write tests against, with a filter that scrubs its own fingerprints out of the site's exported configuration, so the test harness stays out of what the site ships. The second was a development toolkit that repositories fetch rather than copy: one small file each, one command surface, one place to change how everything is built and tested.

Where it got to: vic.gov.au, nearly a decade on

The platform is in service. vic.gov.au(Opens in a new tab/window) runs on it, its repositories are public and still active, and its front-end component library is published for anyone to install.

Each layer, hosting, content management and front end, was designed to be taken on its own, so another agency could adopt just the part it needed. Other Victorian agencies were building on the model within the first 2 years.

Nearly a decade after those first commits, vic.gov.au still runs on the platform.

The work outlived the engagement, and the teams who came after us could keep building on it. That is the outcome we care about most.

For governments bringing many websites onto one platform

Everything on this page is 3 of our services on one shared government platform: architecture for a multi-site Drupal system, development of the modules and the API layer behind it, and the DevOps that builds and tests every repository.

If you run a department, an agency, or a group of sites that each grew their own way, this is the shape the engagement takes: foundations first, tests and pipelines before features, and a platform layer other teams can build on. The same engineering is available with AI-assisted delivery where it suits the work, at the same tested standard.

If you are consolidating agency websites onto one publishing platform, or trying to keep a growing set of repositories consistent, tell us what your estate looks like.

A university web platform is never finished: upgrades, new brands and content migrations

A university website carries a decade of accumulated content, an audience that never accepts an outage as an explanation, and a platform that reaches end of life on a schedule somebody else set. There is always a version to upgrade, a brand to stand up, content to bring home.

Most of that work arrives irregularly and none of it can be deferred, which is an awkward shape to hire for. Victoria University(Opens in a new tab/window) runs its own Web Services team in Melbourne and brings in specialists for the peaks. We have been one of them since 2017.

Working alongside the university's own team: platform engineering from Drupal 7 to Drupal 11

The university's team owns the estate day to day. We provide the platform engineering, the architecture and the delivery practice underneath it, and we hand over what we build as we go. Building technical understanding inside their team has been part of the arrangement from the first year, not something bolted on at the end.

In practice that means:

• a build that runs on Vortex(Opens in a new tab/window), our open-source Drupal project template
• preview environments that appear per change
• automated testing
• release tooling
• hosting
• a rolling programme of upgrades that has carried the estate from Drupal(Opens in a new tab/window) 7 to Drupal 10 and now Drupal 11

For a client, that reads as capacity without a handover cliff: the specialists arrive for the peak, and what they built stays understood inside your own team.

New brands, and content brought home: a vocational site and an institute migration

The university's vocational brand had been sitting inside the main site as a section of it. We built it out as its own website on its own domain, with the university's own team moving the content across.

A few years later we consolidated the separate site of one of the university's policy institutes into the main site. A research institute's whole value is its published papers and the authors attached to them.

So instead of writing scripts for 2 months and finding out on launch night whether they covered everything, we ran the migration continuously throughout the build, proving it against the real content every day. For a client, that turns launch night into a rehearsal you have already run rather than the first full test.

Researcher profiles people can actually find: a searchable directory of academics

An academic profile is commercial infrastructure for a university rather than a vanity page. It is how:

• an industry partner finds a collaborator
• a research student picks a supervisor
• a journalist finds someone to comment

Working to the university's own requirements, our team built its public directory of academics: a profile the academics drive themselves through an editorial workflow, and a search that finds people by expertise rather than by name. Publications, grants and supervision history arrive from the university's own systems, and the rest belongs to the academic to write.

For anything opt-in, adoption is the number that matters. Within weeks of launch, 271 of the 354 academics in scope had a published profile.

Moving the whole platform with no planned downtime: the Lagoon hosting migration

In 2021 both public websites moved onto one hosting platform, amazee.io Lagoon, and every non-production and preview environment moved with them. That second part is the difference between relocating a website and moving a team's whole way of working.

There was no planned downtime, and that came from sequencing rather than heroics. Each site was stood up on the new platform first, its integrations moved and tested there, and the university's team validated it with their own tooling and acceptance testing before traffic followed. Publishing paused for a business day.

What 9 years adds up to: 3 measured results and 2 open-source tools

3 pieces of this work have a number on both sides of them.

• Long-lived sites accumulate weight, and the weight is usually not growth. Most of what was sitting in this one's database turned out to be historical data nothing referenced any more, and removing it left the database 63 per cent smaller.
• Editors on large sites often wait hours for a published change to appear. We measured that end to end and brought the worst case down from most of a day to about 20 minutes.
• Asked to speed up a test suite that took close to 30 minutes, we found 3 of our 4 assumptions about the cause were wrong: the tests were waiting on third-party assets, not on the application. That path ended up about 3 times faster.

A database 63 per cent smaller, and a published change live in about 20 minutes instead of most of a day.

Some of it has come back out as open source. The deployment tooling we first wrote here became drevops/git-artifact(Opens in a new tab/window). And the practice of shipping the development database inside a Docker image, born on this platform so every developer and pipeline starts from real data, grew into drevops/mariadb-drupal-data(Opens in a new tab/window).

9 years, continuous, across 3 generations of architecture. In a market where suppliers rotate every couple of years, that is the outcome we are proudest of.

For web estates that outlive their suppliers

Everything on this page is 4 of our services running on one university estate: development alongside an in-house team, migration of content and of whole platforms, DevOps and hosting, and the training and handover that leaves the knowledge inside the client's team.

If you run a university, a TAFE or another estate that has to keep serving while it changes underneath, this is the shape the engagement takes: specialists who arrive for the peaks, a rolling upgrade programme instead of a rebuild, migrations rehearsed against the real content, and the knowledge left with your own team. The same engineering is available with AI-assisted delivery where the work suits it, at the same tested standard.

If your estate has a Drupal site heading toward end of life, or content sitting in a separate site that should not have one any more, tell us what is on the platform.