Novelis

The problem

Novelis is the world’s largest aluminum recycler and rolled-aluminum producer, a global industrial brand whose corporate site runs on WordPress, hosted on AWS across three environments (development, staging, and production).

Working across multiple environments is standard practice everywhere else in software, but WordPress has no native story for it. Content lives in the database, URLs are baked into that content, and media accumulates in uploads, so keeping a staging environment that actually resembles production means periodically hand-migrating all of it: database dumps, search-and-replace on URLs, media syncs. Done manually, it’s slow and easy to get wrong, so it happens rarely, and teams end up testing changes against stale content.

The approach

As lead developer on the account, my work ran on two tracks.

For the editorial side, I built custom Gutenberg components: a library of on-brand blocks the content team could compose pages from without touching code or a developer.

For the workflow side, I built a migration plugin that clones one environment onto another (production to staging, staging to development, whichever direction the team needed). It packages up what makes a WordPress environment (the database and content, with environment-specific URLs handled in the process) so that a refresh becomes a repeatable operation instead of a checklist of manual steps.

The outcome

Environment refreshes stopped being an event. The team could pull a fresh copy of production into staging before a release and test against real, current content rather than whatever staging had drifted into, which is exactly the safety net you want on a high-visibility corporate site. And the custom block library kept day-to-day publishing in the hands of the content team, with development effort reserved for new capability rather than routine page builds.