We’ve given the content owners of our big, complicated, custom WordPress intranet a great way to safely stage their pages on a private site, then move changes over to the live site without having to copy the entire database.
But when they need to launch a new section of the site, things get very complicated – and deploying a lot of new content to the live site on launch day is a stressful and time-consuming process. Content owners quickly get in over their heads when they try to manage a launch, so developers spend precious hours planning and executing content launches.
Dark launch to the rescue! Borrowing ideas from software companies that use feature flagging of new software to test the waters, roll out gradually, or roll back quickly – we’re gradually moving new content areas over to the live site well before launch day, as the new content is developed.
The cool thing is, no one knows the new content is there until we decide to make it available – not even the search engine – unless we tell them exactly how to find it.
Content dark launch is saving our sanity and giving hours back to our developers, and I’ll explain just how it all works.
Couple of years ago we decided to move the good stuff into wordpress – the stuff ppl care about
Our sweet innocent little SAS Camp page was a nightmare to launch
Our first use of a slider
Asking a content owner to deploy and launch this would be setting them up for failure.
I had been asking content owners how small they could make their launches and it felt wrong.
Devs support the business needs.
I had started following on twitter the founder of a company that does a feature flagging service
What is it? Wrapping features in toggles.
Facebook.
Testing on live.
Continuous deploy / deliver
https://flic.kr/p/9tLMcZ
How do we actually do this?
We need a tool to make it easy to actually move the right pages over to live during the DL phase
“Finding the edges”
The mega menu is easy. It’s managed by hand and changes are small.
Dev and content teams can preview on live
Let’s say we were launching the onsite section AFTER the rest had launched.
Or a team owns part of a shared area – launches tend to be by TEAM (wellness)
Note that the breadcrumb is not a problem
I want to tell you how we hid left nav
But first I have to tell you about the Transporter
Adding pages is easy, moving depends on where it’s moving, and deleting is a pain.
Changing templates can create big changes in deployment
Person in charge of dark launching this section reports in daily scrum whether there were any issues.
List of everything to be deployed
Deflector redirects if needed
Mega menu changes
Redirects
Maybe we do have to RAMP a couple of landing pages that have changes.
And then enter RAMP just to make it even more painful
It really wants to be sure you don’t have bad links or missing images