A release process instead of a release person
A year leading the frontend of a high-traffic sports and media platform, where what reached production stopped depending on one person's memory and started depending on the branch it was on.
- Kind
- Frontend platform and process
- Year
- 2023
- Service line
- Web apps & software
- For
- A high-traffic sports and media platform
- Scope
- Release process and environments, SSO, ad integration, design system
- Built with
- Next.js (SSR), Drupal (headless), REST API
- Duration
- One year, 2023 — a frontend team of four
The brief
This one is shown without its client. The work was real and so was the engagement, but it was delivered in 2023 under another company's banner — DotDash was not the contracting party, and the client is not ours to name. What can be described is the system and the year spent leading its frontend: a high-traffic sports and media platform, with Drupal running headless behind a server-rendered Next.js site, and a frontend team of four.
The code was not the problem. The path to production was. Releases went out through a dedicated release person whose job included knowing which commits were meant to ship that day or that week — the state of a release lived in someone's head rather than anywhere the team could read it. Getting a change from merged to live was long and hard, and on a platform that size the cost of that is not inconvenience. It is finished work sitting unshipped.
What we built
The first thing built was not a feature. Environments and a branch model went in, and together they moved the release decision out of a person and into the repository: everything merges to develop, a separate environment exists to test it live, develop promotes to staging as the release candidate, and staging promotes to master, which is production. Nothing reaches production except by walking that path — so what is in a release is now answered by looking rather than by remembering.
Sign-in was the other thing that had to become safe to change. Accounts ran on a single sign-on service built in-house and shared across the client's other applications, so the frontend was one consumer among several, and a change made in the wrong place could log people out of something it had nothing to do with. The difficulty was never the protocol; it was the complexity of what had grown and the absence of an organised way to work on it. The same answer applied — somewhere to try it before it reached anyone. Third-party integration for advertising and the page's other commercial needs sat in that same frontend and moved along that same path.
Running alongside the engineering was the design system: around fifty components, consumed by the main site, and two designers whose work fed it. Steering both halves was part of the role, and holding them together is the whole point — a design system stays true only while the thing designers draw and the thing developers ship are the same object. Once a component is the unit of change it is also the unit of review, which is what makes a fast release path survivable rather than reckless.
What it does now
The release process outlived the engagement and is still what the platform ships through. Cadence stopped being set by how much of the process one person could carry and became a decision: weekly where that suited, daily where it did not.
No figure is quoted here, and one was within reach — the cadence could have gone daily. But nobody measured the time from merge to production before the change or after it, and a number supplied now would be a guess wearing a decimal point. What can be checked is the shape of the thing: a release path no one has to hold in their head, four environments that each answer a different question, and a design system of around fifty components still standing behind the site. The frontend was the half we ran; the Drupal side was not ours.
- Next.js
- Drupal
- Release process
- Design system
