Magazine Cover Pipeline
A new cover PDF becomes the live cover on every landing page, order page and email that shows one. Nobody touches it. All five TMB brands.
Last Month's Cover
Every new issue, somebody had to export the cover PDF to a JPG, resize it, compress it for the web, upload it to the server, and then chase DevOps to clear the cache. For every brand. Until all of that happened, the landing pages, the order pages and the emails were still showing last month's cover.
Every issue, by hand
- Somebody exports the new cover PDF to a JPG.
- Somebody resizes it and compresses it for the web.
- Somebody uploads it to the server.
- Somebody chases DevOps to clear the cache.
Four moves. Every brand. Every issue.
Drop It, Walk Away
A watched folder is the whole interface. Drop the new cover PDF in and Eventarc hands it to Cloud Run, which converts it to JPG, resizes and compresses it web-friendly, uploads it to the server, and files its own DevOps ticket to purge the cache. It runs start to finish without being asked anything.
01 Drop
- Cover PDFA new issue, into a watched folder(Source)
02 Trigger
- EventarcEvent-driven. No polling.(Process)
03 Convert
- Cloud RunPDF to JPG, resized, compressed(Process)
04 Upload
- Cover on the serverAutomatic. No hand-off.(Store)
05 Purge
- DevOps ticketFiles itself. The cache clears.(Output)
One cover, drop to live. Nothing in this chain waits on a person — and once the cache clears, every page that shows a cover is showing the new one.
The turn
The covers can’t go stale now.
A cover is not one file in one place. It is on the landing page, the order page and the email, and every one of them was as current as the last person who remembered to go and change it. Now none of them waits on anybody.
Where a cover shows up
- Landing pages
- Order pages
One pipeline. Every page that shows a cover.
Current By Default
The covers stopped going stale. A new issue is live everywhere it appears — landing pages, order pages, email — and nobody exports, resizes, uploads or chases a cache purge to make it happen. At roughly three covers a month that is about thirty-six times a year the old chain of manual steps simply does not run.
- TMB brands
- 5TMB brands
- Covers a month — none of them touched by hand
- ~3Covers a month — none of them touched by hand
Those are the two numbers this page has. The cadence is Brian's own estimate and it carries a tilde for that reason. TMB does not publish run times or hours saved for an internal system, so this case study does not either — the rest would be a guess wearing a monospace font.
What It Runs On
- Platform
- Google Cloud Platform — Everything below runs on it.
- Trigger
- Eventarc — Fires per file dropped. Ten covers is ten runs.
- Compute
- Cloud Run — Converts, resizes, compresses. Scales to zero between issues.
- Publish target
- Google Cloud Storage — Where the finished cover lands, for every brand.
- Cache purge
- Jira — The purge is tracked like any other ticket, so it is auditable.
Built by
Mine end to end: the trigger, the conversion job, the upload, and the ticket that clears the cache. I designed it, built it, and shipped it. Creative Technologist, Trusted Media Brands.