Blogging as Code

You may have noticed that our blog recently got a facelift. While redesigning front end sites is fairly common, in our case, this represented a bigger change. We noticed that we weren’t treating our blog with the same principles we apply to the rest of our work. And so we embarked on a journey to find a better way, which lead to our current implementation.

Where We Came From

When we launched our tech blog in 2016, we wanted to create a way for Pluralsight engineers to share the things we were learning with the world. We had two goals in doing so: first, to give back to the communities that had helped us get where we are, and second, to show off the great place to work that Pluralsight is (did I mention that we’re hiring?). In order to do that, it was important that we have a way to distinguish between content by Pluralsight engineers and content by the authors of Pluralsight courses. Our marketing department was very accommodating, helping us build a visually distinctive site at /tech-blog in their CMS.

From the beginning, we chose to use a git repository to store and protect our content. Since we were already using it for all the other important text that we worked with, it just made sense. Formatting is important, but not something we wanted to make the focus of our blog posts (especially while we were still reviewing them), so we chose to write in markdown. Our belief in collaboration extends to writing (though we pair less often on English), and so we used pull requests to give everyone a chance to review what we were planning to publish and help make it better.

When it came time to actually publish a blog post, though, we weren’t as good at using the tools that build the rest of Pluralsight. Every other Friday, one of the (few) developers with full access to our CMS would merge the next post, then spend time manually converting markdown to HTML. Code snippets were especially frustrating, because they involved additional manual effort to get syntax highlighting. We’d then do a bunch of manual verification before finally publishing the blog post, and any typos that we missed involved something closer to a hotfix than a deploy.

A Better Way

There were several things that we felt we needed to make sure we accomplished with our blog. First, we wanted to have an automated publishing process that anyone could run. Second, we wanted to keep things simple enough that we wouldn’t spend a bunch of time on maintenance. Third, we wanted to make sure that continuity was maintained—we didn’t want to break anyone’s links or lose any blog posts. Finally, we needed to be able to keep enough analytics that we’d be able to measure the impact our changes have.

We considered a number of different hosting options, but most of them didn’t give us the level of control we’d need to keep from breaking any links. Hosting it ourselves allowed us a great deal of control, but we worried that it could distract us from more important work. While we find value in this blog, we want to make sure that we spend most of our time focusing on improving Pluralsight for our customers. Then we discovered Hugo.

Hugo uses markdown and templates to create static HTML pages that can be hosted just about anywhere. Because it’s written in Go, the generation engine is available for a wide variety of platforms, so any of our developers can build the site locally to test how their blog post will look. The simple, bare metal templating lets us build the entire tech blog in under a second, facilitating the kind of fast feedback loops that we try to build when we’re developing the rest of the site. Best of all, because Hugo is based off of markdown, converting all of our existing posts was trivial (okay, I built a program to do it, but I probably could have done it by hand almost as fast).

While we considered a few different options for hosting our static HTML, we decided the simplest (since we’re already in AWS) was just to host it as an S3 bucket. Leaving the hosting to Amazon has two big benefits. First, we get to reuse our existing CDN infrastructure, allowing us to serve our content quickly no matter where you are in the world. Second, since AWS is doing the heavy lifting of building and maintaining the hosting infrastructure, we don’t have to build our own monitoring and alerting. If customers depended on the uptime of the site, that might be something we’d want to augment, but for our tech blog, S3’s uptime SLA is more than sufficient.

And so, as of May 13th, we switched all our traffic over to the new site. Our blog now has an automated pipeline, complete with tests (not many, but some), that builds every time a change is committed to master. When we’re ready to publish a change, whether that change is a new blog post or some improved CSS, any developer at Pluralsight can click a single button and deploy to production. Our blog now follows the engineering principles it advocates.

What’s Next

One thing we know is that making changes easy and safe doesn’t slow things down. We’ll continue publishing blog posts every other Friday, explaining how and why we work the way we do. In addition, we’re looking at some further improvements that should make it easy for our authors to receive recognition, while improving your ability to find relevant posts. We hope that you’ll continue to join us as we continue to uncover better ways of developing software.