CircleCI

The question a site answers before anything else: which environment is this?

A surprising amount of what a website does depends on knowing where it is running:

• debug output belongs on a developer's machine and nowhere near the public site
• caching should be aggressive in production and out of the way while someone is working
• sample content and test users are useful in a throwaway preview build and unwelcome anywhere else
• emails should only reach real customers from the real site

So every project asks the same question early in its startup: what kind of environment is this?

The awkward part is that each hosting platform answers it differently, with its own signals and its own vocabulary for its tiers, so the environment a team integrates in goes by a different name on each one.

The result is familiar. Each project grows its own small block of detection code, written fresh, a little different from the last one.

It holds up until a platform adds a tier or a project gains an environment that block was never told about. Then the site behaves as though it were somewhere else, in the one place where being wrong is expensive.

One call, nothing to configure: 6 environment types

environment-detector(Opens in a new tab/window) answers the question in a single call, with no setup. It resolves the environment to one of 6 types:

• local
• CI (an automated build)
• development
• preview
• stage
• production

Everything else in the codebase simply branches on the answer.

It recognises where that code is running:

• the hosting platforms teams actually run on: Acquia, Lagoon, Pantheon, Platform.sh, Skpr and Tugboat
• the automated build systems where the same code also runs: GitHub Actions, GitLab CI and CircleCI
• what it is sitting in underneath: a plain machine, a container, or a local development tool such as DDEV or Lando

Telling a preview apart from development is worth more than it sounds. A short-lived environment built for a single change is not the shared space a team integrates in, and once the difference is visible in code, the settings that follow can finally be right.

For a client, that reads as a preview link that behaves like a preview, and a production site that behaves like production.

Built so a wrong answer is loud: it stops instead of guessing

A detector is only worth having if you can trust it, so the design prefers certainty over cleverness.

A single hosting platform can be active at a time. If 2 announce themselves at once, that is a genuine misconfiguration rather than a riddle to solve, so the library stops instead of guessing.

When a platform is active but cannot place an environment in a tier it recognises, the fallback leans the safe way, towards a shared development environment, and it does not downgrade a platform already known to be production.

There are 2 failures worth engineering against: local settings reaching the live site, and production settings reaching a laptop. The design guards against both rather than relying on everyone remembering.

For a client, that reads as one less way for a site to misbehave after a deploy: debug output, caching and test data follow the environment the code landed in.

One line in a Drupal settings file, and a plain call anywhere in PHP

For Drupal(Opens in a new tab/window) the integration is a single line in the site's settings file. That line works out the environment and applies the settings that belong with it, so trusted hosts, file paths and caching are correct wherever the code has landed, with no per-project block to maintain.

Outside Drupal it works through a plain call in any PHP application. It is also built to be extended, with the same pieces the built-in platforms and frameworks use.

Drupal is the framework integration that ships today, and the model underneath it was designed to be framework-agnostic from the start.

Why we keep it public: shipped in Vortex, free to adopt

Solving this once is the entire argument. It ships as part of Vortex(Opens in a new tab/window), our open-source Drupal project template, so every project we start already knows where it is running, and supporting a new host becomes a package update rather than an edit in every codebase.

One call, 6 environment types, and the same answer on every supported host.

It is open source and free to use, published on GitHub(Opens in a new tab/window), so any team can adopt it without ever speaking to us. That is deliberate.

This is unglamorous plumbing, it is the same in every project, and no budget should be paying to write it a second time.

When we take on a platform, that habit comes with us: the generic parts are already solved, so the effort goes where your platform is actually different.

For teams whose environment logic is hand-written in every project

Everything on this page is 2 of our services pointed at our own tooling: the development of the library itself, and the ongoing support and maintenance that keeps it current as hosting platforms change. The same standard applies to our AI-assisted delivery: whatever writes the change, the environment it lands in is decided by one tested library rather than by a block of code copied between projects.

If you run a Drupal or PHP platform whose settings file carries its own environment logic, or a team working across several hosts that each name their tiers differently, this is the shape the engagement takes. The detection moves into one tested library, the per-environment settings follow from it, and adding a host later is a version bump instead of an edit in every repository.

If nobody on your team can say for certain what your production site would do on the day it decided it was staging, send us your settings file.

Everyone builds the same components, separately: navigation, cards and accessible forms

Every public-sector website needs the same handful of things:

• a navigation people can actually use
• a card, a button, a form that works with a screen reader
• pages that read unmistakably as official

Most organisations pay to build all of it again, from scratch, on every project.

The cost is not only the first build. It shows up again when a component changes and nobody can say which of your sites carries which version, and again when accessibility arrives late as a remediation ticket rather than early as a default. And the sites drift apart until services meant to feel like one government no longer do.

A shared design system converts that repeated spend into a single maintained asset. Designing one is the easy half. The hard half is maintaining it so that the teams downstream can take an update without fear.

What CivicTheme is: a UI Kit, a Drupal theme, modules and a Figma source

CivicTheme(Opens in a new tab/window) is an open-source, component-based design system published by Salsa Digital(Opens in a new tab/window). Its own documentation puts the purpose plainly: it was created "so governments and corporations can rapidly assemble modern, consistent and compliant digital experiences".

4 parts ship, and they stay in step:

• a CMS-agnostic UI Kit of components built with HTML, CSS and JavaScript, browsable in Storybook
• a Drupal(Opens in a new tab/window) theme that connects the content model to those components
• supporting modules, including one that adapts the theme to the federal GovCMS(Opens in a new tab/window) platform
• a Figma design source that carries the same version number as the code, so a designer and a developer are provably looking at the same release

Accessibility sits in the baseline rather than in each agency's budget. The documentation is explicit: "The components have been built and assessed to comply with WCAG accessibility standards 2.1 AA out-of-the-box."

Our part in the work: architecture, release engineering and maintenance since 2021

Salsa Digital publishes CivicTheme, hosts it and runs its community. We wrote its first commit in September 2021 and have provided the engineering behind it ever since:

• architecture of the component system
• development of the components, the theme and the supporting modules
• release engineering, to drupal.org and to npm
• ongoing maintenance as Drupal, PHP and GovCMS move forward

Everything is developed in one repository and published out to the separate ones people install from. Develop together, ship separately: that one decision lets a small team keep a theme, a component library, companion modules and a documentation site moving in step.

Underneath it, the build and continuous integration run on our own open-source project tooling, the same tooling we bring to client platforms. For a client, that reads as inheritance: the build and test discipline behind a public design system arrives with us on your own platform.

Making an update safe to take: visual regression and schema update tests

Components exist in 2 forms, Twig templates and Drupal Single Directory Components, so that Drupal consumers and non-Drupal consumers each get the implementation they need. Keeping 2 versions of every component honest by hand would be untenable, so parity is machine-enforced: tooling synchronises them, and a check command fails the build the moment they drift.

The primary defence is visual. A unit test cannot tell you that a button moved 4 pixels, and teams downstream notice.

So every pull request captures screenshots of the components, publishes a side-by-side comparison and posts the link back into the review conversation where someone will actually read it. The same pipeline does double duty: one comparison catches a visual regression against the released version, the other catches drift between the 2 component implementations.

Then there is the question every organisation actually asks: what happens to our site when we take the update? Because the system ships configuration for content types, fields and site settings, updates are rehearsed against committed database snapshots, both schema-only and schema-with-content, before they reach anyone.

For a team downstream, that is what makes an update routine rather than a project: the change has been rehearsed against a database shaped like yours before it reaches you.

Release rules follow the same instinct: on drupal.org, where a release cannot be deleted, only the development branch is ever pushed.

Where it is now: Drupal 10 and 11, GovCMS, and 4 content profiles

Live and in service. Published on drupal.org and on npm, documented at docs.civictheme.io(Opens in a new tab/window), with the component library and a live demonstration site online.

4 industry content profiles ship alongside a default:

• Corporate
• Government
• Higher Education
• Health

Each is a complete worked example rather than a starter shell, so a team can watch the system do the job before committing to it.

It tracks the platform forward: Drupal 10 and Drupal 11, current PHP, GovCMS support kept current. A steady release cadence has carried it across 4 years, with a pre-release channel so teams can test a release candidate before they take it.

A single maintained design system, 4 industry content profiles, and 4 years of steady releases.

4 years on, we are still the engineering behind it.

For teams rebuilding the same components on every site

Everything on this page is 4 of our services running on one public open-source design system: the architecture of the component system, the development of the components and modules, the DevOps and release engineering that ships them, and the ongoing support and maintenance that keeps all of it current. The same standard applies to our AI-assisted delivery: whatever writes a component, the visual comparison and the schema update tests are what decide it is safe to release.

If you run a government agency, a university, or any organisation with a family of sites that keep drifting apart, this is the shape the engagement takes: a component library that is genuinely shared, accessibility in the baseline rather than in a remediation ticket, and updates rehearsed before they reach your site.

If you are weighing up CivicTheme for your next site, or you already run it and want taking an update to be routine, tell us which sites you are trying to keep in step.

What you push is what production runs: deploying from a git branch

A good deal of hosting still works the simplest way there is. You push to a git branch, the platform notices, and it deploys whatever it finds there. It is a clean model, and it puts an awkward requirement on your repository.

Your repository is not what production needs. It carries the parts a team builds with:

• development tooling
• test suites
• source assets
• build configuration

What it does not carry is the compiled CSS, installed dependencies and vendor code the running site depends on. Something has to bridge that gap, and for most teams that something is a deployment script written once, under time pressure, and then trusted forever.

That step is worth thinking about carefully, because of everything in a pipeline it is the one that can fail quietly.

A build that breaks stops the pipeline and tells you. A deployment that publishes the wrong contents raises nothing at all. It simply goes live.

A deployment step designed to refuse: dry runs, no-change guards and tag collisions

git-artifact(Opens in a new tab/window) builds the deployable artifact inside CI and commits only that to the separate repository your host watches. Development tooling stays out of the deployed package, which keeps the running site lean and narrows what is exposed there.

The part we care about most is what it does when something is not right. It refuses in 3 independent ways, each covering a different way a deployment can go wrong without anyone noticing:

• pushing is a dry run unless you explicitly ask for a deploy, so the default invocation prints what it would do and writes nothing to the remote
• if the artifact it has just built is identical to what is already deployed and no new tags are involved, it stops rather than adding noise to the history
• if a tag would collide with one already on the destination, it stops there too

For a client, that reads as a deployment that stops rather than guesses: when something does not look right, the pipeline says so instead of publishing quietly.

Underneath those refusals sits the ordinary work of getting an artifact right:

• a manifest controls exactly what goes in
• a watermark in each commit message lets the tool find where it left off on a repository it does not own, which is what makes incremental artifact builds possible at all
• tags are carried across with collision detection
• symlinks survive the copy instead of being flattened into broken files

All of it was built test first, against a suite that provisions real throwaway git repositories rather than mocking them. Testing a deployment tool that way is slow and awkward. It is also the only way to know the safety rails actually fire.

Where it came from: a 2017 client audit, extracted as open source

git-artifact started inside client work. In 2017 we were auditing a dual-sector university's TAFE website platform, and we rebuilt its deployment step from the ground up: written test first in PHP, with the refusals above and a test suite that exercised every one of them.

2 years later, we did the part that mattered more. We lifted it out of the client's codebase and published it as a standalone open-source package, so every project after it inherited the same tested deployment step at no cost to anyone.

That is a habit rather than a one-off. When client work produces a piece of engineering that is better than that one project strictly needed, we take it out, publish it and maintain it. git-artifact is the earliest example and still the clearest one.

For a client, that habit reads as inherited engineering: the deployment step on your platform arrives already built, already tested and already maintained, rather than written fresh under time pressure.

Still deploying, 9 years on: Vortex, Acquia Cloud and Lagoon

git-artifact is maintained and in service 9 years after the first version and 7 after it became a package. It ships with Vortex(Opens in a new tab/window), our open-source Drupal(Opens in a new tab/window) project template, and it is the deployment mechanism for Vortex-based projects on git-deployed hosting, including Acquia Cloud and Lagoon.

9 years in service, 7 of them as an open-source package other projects inherit.

For a tool whose whole job is to say no at the right moments, longevity is the measure that counts. It has been doing the same careful thing in other people's pipelines for the better part of a decade, and the teams using it rarely have to think about it.

For pipelines whose deploy step nobody has read

Everything on this page is 4 of our services pointed at our own tooling: the architecture of a deployment step, the development of the package that implements it, the DevOps engineering it exists to protect, and the ongoing support and maintenance that has kept it current since 2017. It is the same rule we apply to AI-assisted delivery: however quickly a change is written, it reaches production through a deployment step that has been tested.

If you run a site deployed from a git branch, on hosting like Acquia Cloud or Lagoon, and the step that gets your build there is a script somebody wrote once, this is the shape the engagement takes. The deploy step becomes a tested, maintained package: a dry run by default, a refusal when something does not look right, and only the built site in front of your visitors.

If nobody on your team can say what your pipeline actually pushes to production, show us your deploy step.

When a website is where people go for health, housing and concessions

People arrive at a health and human services website with a real question, often at a difficult moment:

• someone checking whether they qualify for a concession
• a parent trying to understand a family service
• a nurse looking up clinical guidance
• an adult asking for the records of their own childhood in care

The site either answers the question or it does not.

The Victorian Department of Health and Human Services ran one of the largest web estates in the state, covering consumer health information, concessions, housing, disability, family services, records access, and clinical guidance for the health sector. Many audiences, many editorial teams, one shared expectation that the information will be right and reachable.

Drupal engineering inside the Salsa Digital partnership

The work reached us through Salsa Digital(Opens in a new tab/window), a government digital agency whose teams carried strategy, design and content across the department's properties. We joined as their engineering partner and stayed for 4 years, providing:

• platform engineering
• build and release tooling
• Drupal(Opens in a new tab/window) development
• content migration
• decoupled front-end work

Some of it was new architecture. A lot of it was the quieter work of making several teams' releases predictable.

Several audiences, one Drupal codebase and one content platform

3 of the department's public websites, serving citizens, funded organisations and service providers, were consolidated into a single Drupal codebase. One map of the estate drives everything downstream: the build, each site's settings, deployment, the test suite and the theme. Each site keeps its own visual identity through configuration rather than code, so an editorial team can change how their site looks without waiting for a developer release.

A separate content platform then decoupled the department's content from its presentation, so several front ends could share one editorial spine. It carried a consumer health encyclopaedia, professional guidance published as open data, service directories with eligibility and access details, and a records access service. Editors describe intent, such as whether a page offers text to speech or a printable version, and each front end decides how to honour it.

Built for the people on the other end: accessibility and a link-safe migration

The front ends built on that platform are server-rendered JavaScript applications, and 2 things matter about how they behave. Every part of a page is assembled independently, so one troublesome component degrades on its own instead of taking the page with it.

The second is accessibility, treated as implementation rather than aspiration:

• screen-reader headings
• focus management on dialogs
• proper tab and panel semantics for medical citations
• built-in text to speech

Migration mattered for the same reason. People bookmark government pages, print them, cite them in letters and share them in community groups, and search engines have years of them indexed.

The migration was built so those links survived: content from the legacy system was rebuilt as structured, reusable page components, and old-style page and document addresses were resolved on the new platform and served the right file. For a client, that is what a link-safe migration buys: the address saved in a bookmark or printed in a letter still leads somewhere after launch day.

Built once, released safely: containers and continuous integration

Underneath all of it we changed how the code was built and shipped. In 6 days in 2018, a live government Drupal site moved onto containers and managed dependencies, with the application built exactly once, in continuous integration, and that identical build used everywhere afterwards.

One self-documenting set of commands ran it, so every developer and the pipeline did the same thing. Releases were designed to fail quietly: a dry run by default, and a release that did not complete cleanly left visitors seeing the site exactly as it was. For a client, that is what a safe release means: a release that does not land costs you a wait, not a broken site.

What it left behind: 2 open-source tools still shipping

We worked across 4 of the department's properties over 4 years, and the tooling outlived the engagement.

2 things that began as answers to real problems on these sites are open source today and still maintained. drevops/behat-steps(Opens in a new tab/window), a library of reusable automated test steps for Drupal, was extracted from the department's sport and recreation site and later became a dependency of the Victorian Government's central content platform.

And the containerised project template built in that week in 2018 is the direct ancestor of Vortex(Opens in a new tab/window), the open-source Drupal project template we ship on every project today.

4 properties over 4 years, and 2 of the tools built for them are open source and maintained today.

That is the part we are proudest of: solving a real problem twice, then giving the answer away.

For government estates where the information has to be right

Everything on this page is 4 of our services running across one government web estate: architecture and development on a shared Drupal codebase, content migration that keeps the addresses people already have, build and release engineering, and accessibility built in rather than bolted on.

If you run a government web estate, a health service, or several public sites that share one editorial team, this is the shape the engagement takes: one codebase behind several sites, migrations that keep existing addresses resolving, and releases safe enough to be routine. The same engineering is available with AI-assisted delivery where it suits the work, at the same tested standard.

If your estate has spread across several ageing sites, or a migration is coming and the links people already have worry you, tell us what the estate looks like.

When a website has to sell a regulated product: energy pricing before a quote

Most websites show a price. An energy retailer's website has to work one out first.

Before anyone can be quoted, the platform has to establish:

• which meter sits at their address
• which distributor serves it
• which tariffs apply
• which offers may legally be sold in that state

Only then is there a number to put on the screen. That chain runs live, while someone waits on a form.

Everything attached to it is regulated too, from the fact sheet that accompanies every offer to the wording on the offer itself. It is a transaction engine wearing a website's clothes, and it still has to stay editable by the marketing team.

Our part in the work: Drupal architecture and the delivery toolchain

The client is a national energy retailer, selling electricity and gas to households and small businesses across several states and territories. In 2020 it replatformed its public website onto Drupal(Opens in a new tab/window).

We were engaged through a partner agency, which ran the delivery programme, as the Drupal architecture and platform engineering partner, while a specialist design agency supplied the experience design.

Alongside the architecture, we stood up and ran the delivery toolchain the whole engineering team worked through:

• the source-control organisation
• the continuous integration account
• the automated code quality checks
• a containerised local environment so every developer ran the same stack

For a client, that shared setup reads as consistency: every developer on the programme worked to the same checks, whoever they worked for.

The brief itself was easy to state and hard to build: let the marketing and sales teams manage their own offers and content.

5 sign-up journeys, and one of them is moving house

The platform carries 5 separate sign-up journeys rather than one, because a household, a home office, a small business and a specialist offer are each sold and priced differently. The main one is a 5-step checkout.

Moving house has its own 7-step flow. Relocating is the highest-intent moment in energy retail, and it asks different questions: when the power needs to be on, and what a technician will find at the property.

That last part is what separates this from an ordinary web form. The output of the funnel is a work order for someone who will physically attend a house.

Around them sit the things regulation requires:

• energy fact sheets issued as part of the flow
• separate concession forms for the states that administer them their own way
• payment handled by dedicated providers

An address is not an address: validating it into a regulated meter identity

The hinge the whole funnel turns on is a translation the customer never sees. Someone types a street address the way they would write it on an envelope.

The platform validates it, then converts it into the shape the national electricity market registry expects, so a typed address becomes a regulated meter identity.

If one meter matches, the journey continues without the customer noticing. If several do, they pick from a short list. Electricity and gas resolve separately.

Everything downstream depends on that one step. Without a meter identity there is no distributor, without a distributor there are no tariffs, and without tariffs there is nothing that can lawfully be sold. It looks like a form field and it is actually the architecture.

Editable by the people who own the offers: a content model marketing can run

Energy offers change often and their presentation is regulated, so the people accountable for the wording need to change it without waiting for a release.

The offer model was built so every element of an offer card is separately editable, and page structure lives in a visual layout builder rather than in code. Giving the business that control was the stated goal of the replatform, and it is the part that outlasts a redesign.

For a marketing team, that reads as autonomy: changing the wording on an offer is a content edit, not a release.

What we carried forward: request logging and integration health

2 ideas from this build have shaped how we approach integration-heavy platforms since.

The first is request-scoped debug logging: when one page depends on a dozen live calls to other systems, you want the story of a whole request in one place, not scattered across log lines.

The second is treating the health of those integrations as a feature, so anyone can see which upstream systems are answering. We have since built that idea into a package of our own.

5 sign-up journeys and a 7-step move-home flow, all hanging off a single address lookup.

Most people picture Drupal as a content site. This was a regulated transaction engine with a content site attached, and the content management was the least interesting part of it.

For platforms where signing up is the product

Everything on this page is 3 of our services running on one regulated acquisition platform: Drupal architecture for a transaction-heavy build, development against live upstream systems, and the delivery toolchain and containerised environments the engineering team worked through.

If you sell a regulated product online, in energy, insurance or telecommunications, this is the shape the engagement takes: an architecture built around the one lookup everything downstream depends on, sign-up journeys designed per customer type, and a content model the business can change without a release. The same engineering is available with AI-assisted delivery where it suits the work.

If your sign-up funnel is the slowest part of your platform to change, or your quoting depends on systems you do not control, tell us what the funnel has to do.

The 2 costs nobody puts on the budget: setup and drift

Ask a team that runs more than 1 Drupal(Opens in a new tab/window) site where its time goes, and 2 answers come back.

The first is setup. Every new project spends weeks on the same groundwork before anyone builds a feature:

• local environments
• CI pipelines
• hosting wiring
• code quality tooling
• a test harness

The second is drift. Once a project is running it grows its own arrangement of tooling, so a year later moving a developer between 2 of your own sites means learning 2 different machines.

Neither cost appears on a budget line, and both are paid again on every project.

Installed once and kept current: local environment, CI pipelines and hosting

Vortex(Opens in a new tab/window) is a Drupal project template: a tested foundation you install once, pick features from, and then keep current for the life of the project.

The template is the pre-configured Drupal project itself, wired together and working on day 1:

• a containerised local environment
• CI pipelines
• hosting integrations
• code quality tooling
• a testing harness

Documentation ships with it, including an onboarding checklist for new team members. An installer adds only the features you chose, from hosting and CI provider through to theme and AI agent instructions. On the current line that tool is the installer; the next major moves the job into a dedicated Vortex CLI.

That upgrade path is what separates Vortex from a starter kit, which is a one-time copy frozen at whatever it got right in its year. Vortex keeps the path open, so a project set up in its first year can adopt improvements made in its third through the same tool that created it.

For a client, that reads as continuity: the foundation under your site keeps getting the improvements made after your project started.

Whichever features you pick, local, CI and hosting all run the same provisioning path. That single decision is where "works on my machine" stops being a recurring argument.

The quality gates arrive switched on: secret scanning, static analysis, 90 per cent coverage

Plenty of templates leave quality tooling as an exercise for the reader. Vortex ships the gates configured and running across the whole codebase:

• secret scanning
• dependency auditing
• container linting
• static analysis
• coding standards

A 90 per cent code coverage threshold fails the build by default, with the result posted back onto the pull request. Visual regression waits behind an opt-in label, so an expensive check runs only on the changes that warrant it. Third-party CI actions are pinned by commit hash, a ready answer to a supply-chain question many teams are now being asked.

Every gate can be switched off with a single variable, and that matters more than it sounds. A team can adopt the pipeline on day 1 without being blocked by it, then tighten it as they go. It is the difference between a pipeline people keep and one they quietly delete.

The documentation is held to the same standard: linted, tested, and gated against drifting out of step with the code.

9 years in and busier than ever: 111 releases across Drupal 7 to 11

The usual failure mode of a project template is quiet abandonment: excellent for 18 months, then attention moves elsewhere and the repository goes still.

Vortex began in July 2017 and has shipped 111 releases since. It has tracked Drupal 7, 8, 9, 10 and 11 across their lives, and today it targets Drupal 11.

Releases go out on a stated monthly cadence, borne out across the recent run. A second major version is already published alongside the first, with the release plumbing built so that promoting a new major to the default is a single configuration change.

It is being developed more actively today than in any year of its life.

111 releases since 2017, across Drupal 7 to Drupal 11, and busier today than in any year of its life.

For a client, that history reads as low risk: the foundation under your project is maintained by the team you are already working with.

Open source under GPL-3.0, and used on the work we are paid for

Vortex is open source under GPL-3.0 and developed in public: repository, issue tracker, releases and documentation are all open. Community support runs through Drupal Slack and GitHub issues, and paid support is available for teams that want a commercial contact behind it.

We use it ourselves, which is the part that keeps it honest. Our own website runs on Vortex and is offered openly as a reference for what a long-lived Vortex project looks like, and the client platforms we support run on it too. The template meets real delivery pressure, not only its own test suite.

The flow runs both ways. Tools that began inside client work ship with Vortex, including our Behat step library(Opens in a new tab/window), CI runner image(Opens in a new tab/window) and artifact deployer(Opens in a new tab/window). Pieces that outgrow it are published in their own right.

For teams paying the setup cost on every Drupal project

Everything on this page is 4 of our services pointed at our own product: the architecture of the template, its development, the DevOps and hosting wiring it ships with, and the support and maintenance that has kept it current since 2017. The same template ships the AI agent instructions behind our AI-assisted delivery, and the gates decide what is allowed to merge.

If you run a portfolio of Drupal sites, or a team that starts a new project every few months, this is the shape the engagement takes: your sites build, test and deploy the same way, new developers onboard against a stack they have seen before, and improvements arrive through the same tool that set the project up.

If your Drupal projects have each grown their own build and nobody can move between them, tell us what your setup looks like today.

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.