How we allow anyone to make and publish changes to our site
When we first started Pixlee, things were pretty simple. We had a single monolithic Rails application that powered everything from the web application to background workers to landing pages. As we grew the business and the platform, that monolithic application became a collection of systems and services.
When people ask questions about our tech stack, they usually mean our application servers. One often overlooked and valuable portion of that stack is our content site; all of the marketing copy, landing pages, and blog posts that help us tell the Pixlee story. As our non-technical staff grows, it's become imperative that they be empowered to make changes to the content site quickly without technical assistance. We believe that our content process should be as agile as our software development process.
We were able to settle on a workflow inspired by the folks over at Asana who wrote a great blog post detailing their use of Statamic, an incredibly awesome file-based CMS. Here's our take on the Asana team's workflow:
Increased accessibility through the GUI
The biggest deviation is that we keep the Statamic Control Panel enabled on our staging server and make extensive use of Fieldsets to create custom page types. The power of Statamic lies in its extensibility - designers are not limited at all by the CMS and can empower non-technical teammates to jump into an easy-to-use GUI and make changes to content without affecting design. Anyone at Pixlee is able to dive into the staging Control Panel, make changes and immediately see the results as they would appear on the actual site in real-time, all without worrying about "breaking the site". This is a pretty powerful proposition.
Everything is backed by Git transparently
We like having everything backed by Git but didn't want people navigate through files and folder structure of GitHub that they really don't need to know or care about. We have a hosted Git repository hosted that everyone can push to and pull from without even realizing it. This Git repo is the single source of truth for our content.
Every time a teammate creates, alters, or deletes content, we perform the relevant Git actions in the background and push them to our repo. And, because they are editing content on the staging server itself, they can quickly see the results of their changes without having to navigate to another URL. At the same time, technical teammates can make changes locally and push to the repo as well, which will then update the staging server using a post-receive hook and notify anyone working on content that a developer/designer has pushed changes.
We've extended Statamic with Git functionality and a lightweight websocket-based alert system to achieve the above and could not be happier with how easy of a process it was.
Deployment
Deployment is handled by a technical member of the team who reviews all changes and merges into the production branch when ready. Afterwards, it's a simple push to Codeship which then deploys to our production Heroku server. This is a pretty quick process and is more of a sanity check to that ensure nothing goes wrong.
Impact
Before we switched to Statamic, we had a hodgepodge of static pages served by Rails directly for the core marketing copy/pricing pages and Wordpress (reverse proxy from the Rails app) for blog and landing pages. This was a very hacky setup and led to a lot of unnecessary lead time on things as simple as switching a sentence on the Rails-backed pages or a lot of frustration when working in Wordpress. More distressing, our content workflow did not reflect the agile processes that are the trademark strengths of a small team.
As a startup, time is our most scare resource and pulling a developer or designer to perform incremental website changes would be a painful context switch, so a lot of changes were simply left on the bench.
Now, anyone can make changes to the site, see it in staging in real time, and have it deployed within minutes without having to re-deploy our core application server. And because we've empowered the entire team to make changes quickly, people are more interested how our site performs and how we can improve it.
It's hard to understate the profound impact this has already had on the team. We're incredibly excited by the possibilities that lay ahead now that everyone in the company can contribute to the site. We echo the Asana team's belief that when it comes to scaling your content, it's really a team effort if you have the right tools.
