Why It Took Us Two Months to Rebrand ChallengePost to Devpost

 | 
featured image

By Neal Shyam, Marketing & Community at Devpost.

Devpost is the home for hackers, a community where you can meet great developers, build a portfolio of your work, and compete in online & in-person hackathons. We think it’s important to tell the story behind your code.

Why We Rebranded

When we started ChallengePost in 2009, it was a platform for online competitions (challenges). And back then, challenges could be about anything: videos, ideas, software, recipes, etc.

About two years ago, we noticed that our best and most inspiring challenges were about software and tech. We shifted our focus solely to software developers hackers and got more involved in the hackathon scene & building tools to help hackers celebrate & showcase their projects. And in July, we decided to rebrand to reflect that shift and our commitment to it.

Two Months to Make DNS Changes?!

You might think that, tech wise, rebranding is easy. Once the design & marketing team figure out the creative stuff, it’s just one big find / replace. Change the logo, some CSS and text, fiddle with DNS, redirect to a new URL, and you’re done—right?

It might be that easy in some cases, but it’s largely dependent on the context. (And FYI, it took Holly and me ~ four months to do the “creative stuff.”)

At Devpost, that context included many disparate factors like our users, product, business needs, infrastructure, data, integrated services, email deliverability, SEO, code base, etc. Each one of these factors came with its own caveats and issues. Just being aware of them was hard enough. Coordinating the changeover to minimize potential problems required a lot of planning.

devpost-02

Ross, our CTO, created a Trello board to capture all the concerns his team needed to address. In many cases, it simply listed what we knew to be the problem and what we believed to be its importance. The list included things like:

  • Facebook users must be able to login on Devpost
  • Hackathon homepages must render on the new domain
  • Redesign the site with new logo and theme
  • Images served from CDN via new domain
  • Automated emails are delivered from support@devpost.com
  • Spam detection service integrated with new domain
  • Warming up our new email domain on MailChimp and adding DKIM & domain verificiation
  • Company blog hosted on new domain
  • Social media changeovers

And oh yeah, we also needed us to perform this switch before the fall hackathon season and with minimal impact to existing clients. In other words: as fast as possible and with no mistakes!

Shadow Domain

In preparation for the big day, we spun up sister versions of the site for our staging and production environments. This meant that devpost.com could be live well in advance on the switch without concerns about DNS latency. We were also able to upgrade key dependencies of our architecture (e.g. Ruby and Redis) on the Devpost stack and troubleshoot those changes without affecting our challengepost.com production environment.

The tech team also needed several weeks to work through changes in the codebase. In addition to the surface-level changes, like the new site design, they needed to refactor out a bunch of assumptions in the business logic and our data, most notably, the domain on which we served the site. Making these things configurable enabled us to run the site on arbitrary domains—something that might be easy to do for a brand new business—for us, was not straightforward. This meant working through several years of accumulated business and technical decisions that were impeding the current needs.

Compromises

As with all choices in tech, there are tradeoffs and not everything we needed could be accomplished in advance. To maintain continuity with our OAuth providers, like Facebook and GitHub, we had to switch settings manually during the transition.

By running two versions of the site, we also needed to ensure data continuity. We could have tried a number of things, like sharing the database layer or setting up a parent-child relationship between the stacks. But, after working with the team at EngineYard, we decided the easiest approach would be to shut down site traffic and run scripts to import the data one time between the stacks during the transition.

ProTip: Call your hosting providers in advance and ask for their help. They’ve probably done this before.

Playbooks & Practice

When we realized we’d have a number of steps to work through during the transition, we wrote a playbook to orchestrate the changes. Steps included “Put up maintenance page”, “Shut off background processes”, “Trigger mysql backup”, “Kick off Chef recipes”, “Enable nginx redirects”. This level of detail meant we could assign roles to each member of the development team.

Ross and his team also performed several “dress rehearsals” on our staging environments, so that every member of the team had the experience of working through his or her role and potential problems that might arise.

Game Day

On Game Day, July 28th, we were online before 6am ET (Ross was at the office at 5:15am.) to make final preparations before kicking off the rebrand at 6:30 in the morning. After some tense moments of running scripts, changing settings, and monitoring the system, Devpost was live to the public before 7:15am. Tech spent the remainder of the morning on followup tasks like additional settings changes and CSS tweaks that we had punted on earlier.

By noon, at what felt like the end of the day, it was time to celebrate with champagne from the boss and ice cream cake. Success!

ProTip: Remember, no matter how much you test, the only place where issues in production happen is in production!

More than Code

Upstairs in the marketing loft, I chewed my fingernails waiting for CNAMES to start working and preparing to update our social media profiles. Unlike the tech team, I couldn’t practice or rollback most of these changes:

  • The official process for changing your twitter handle is to log in to both accounts @old & @new), change @new to @temp, change @old to @new, and change @temp to @old.
  • Google+ will let you change your display name, but not your username/url.
  • I accidentally leaked the news when he changed our Facebook page name a few days early—which is supposed to take an indefinite amount of time to clear—and the change went through automatically. And of course, you can’t change your page URL or name more than once.
  • Later, I learned the best thing to do is call your Facebook Ads rep and tell then you’re rebranding.
  • Changing our Tumblr blog over @DevpostHacks was probably the easiest change we made, all it took was a CNAME & and a new theme courtesy of Holly.

#SQUAD

devpost-03

Rebranding was a major team effort and our team executed it quickly and with minimal issues. It was a great show of solidarity, efficiency, and most importantly, planning. If you have any detailed questions about what we did or how we did it, tweet us @Devpost!