Greg Boone

Tag: DevOps

What I learned setting up WordPress on cloud.gov

Since around June, I’ve worked on 18F’s cloud.gov product and this week marked my last quarter on the team. We end every quarter with a so-called “innovation and planning” sprint. The product managers do the planning and the team members do the innovating. Innovating in this context means working on parts of the product that will benefit users that aren’t part of the normal business work. I chose to work on improving the WordPress example app we maintain for our users.

If you’re not familiar, cloud.gov is a Platform as a Service built by federal employees and designed around the specific security and regulatory concerns federal agencies need to consider before they’re authorized to launch a web product. No matter how big or small, whether it has open data or national secrets, all information systems operated by the federal government are required to undergo some kind of evaluation against standards published by the National Institute for Standards and Technology (NIST). The result of this process is the granting of what’s called an “Authority to Operate,” or ATO. Basically, an ATO says that the system meets the requirements outlined by NIST and the agency has accepted any risks the system might present. If an agency runs several websites they end up with a lot of repetitive documentation for components that may be the same across each individual app. cloud.gov attempts to solve this problem by standardizing many of those common components so that the agency only has to worry about the parts of the application that serve their mission directly.

It’s a fully open source and based on the Cloud Foundry PaaS project. Compared to how I’ve launched and managed WordPress sites in the past it’s a pretty big shift in how to think about the product. The main shift is finding ways to not rely on the filesystem.

To do that means pushing your uploaded files straight to S3 or another cloud storage service. It also means session information needs to be stored in a cloud service like redis. Most of the example we cribbed from Cloud Foundry’s example WordPress app but due to slight differences in our infrastructure environment, we needed to make a few alterations. The most significant was the recommended plugin for connecting to S3. Cloud Foundry’s example used a more robust AWS plugin but one that required extra effort for us to connect to Amazon’s GovCloud environment. Using that plugin meant installing two plugins from WordPress and then writing and maintaining our own helper plugin to interface with them. Human Made’s plugin was a drop in plugin that already pulled credentials from the environment and was much simpler to configure for cloud.gov.

Getting this up and running reminded me of the work I did at CFPB getting their then-WordPress site — the last major WP site I worked on — into a stable, easily deployable production environment and how much easier that all would have been with cloud.gov at our disposal.

We configured WordPress very similarly to how cloud.gov arranges the pieces. Uploads were synced to S3 and we heavily cached the site — including the local session. The difference is that we spent weeks, maybe even months, writing and maintaining a Fabric project that could install plugins, update the themes, and manage the version of Core we ran in production and then getting our CI server, Jenkins, to automate the deployment of it all. We ended up with a well-functioning DevOps flow for consumerfinance.gov that didn’t require any of us to be physically around whenever someone needed a deployment to happen. All of that was good and important work, don’t get me wrong, we were rightly proud of what we did. The point is that a product like cloud.gov could have saved us a ton of time because a lot of that orchestration is done behind the scenes.

If we’d had a platform like cloud.gov to start from, we could have saved ourselves a lot of that work and focused on other things closer to our mission.

WordPress was the first open source project I ever worked with and the one that taught me how to be a professional developer. cloud.gov has the potential to make government web applications faster, more reliable, and more secure. The two of them together make up a giant stack of open source code. I’m glad I had a chance to bring these passions together.

Your Comms Team Needs A Developer

I recently started working at 18F as their first “comms person” which in a startup environment means you’re the person who does everything, just like everyone else, but you focus on writing blogs, publishing the website, and pitching new ideas for how we might communicate about what we do. Most of my work has been on the
website
and a dashboard of all the work we do which has taught me a really important lesson: your website and how it is made, is just as much a communications artifact as anything else your comms team produces.

Despite being on a communications team, I still write a lot of code. Writing code, or being able to jump in and learn some, is increasingly important in all kinds of jobs where people never used to have to write any code, and
communications is no different if only for the simple fact that communications teams often end up owning most of the content and design of their organization’s website and if that website can’t meet their needs it causes rifts of trust between throughout the organization. Be they operational, managerial, or customer facing, a breakdown in trust is toxic and results in the web seeming useless to everyone.

Often this happens because the website was designed and developed to spec by a freelancer or consultant on a one-time contract. An “expert” stands up a shiny looking website that does everything the organization wants it to do, trains a few people how to use it and leaves. Months (days?) later when somebody wants to put more than one photo on a page, they contact the IT
department and are told “pages may only have one picture and it cannot be larger or smaller than x by y dimensions.” (True story.) Software is not static, as people use it, they discover how it can do more for them. Imagine if Microsoft stopped developing Word after it’s initial release. Nobody would use it because it would no longer be valuable.

What an organization can do with its website is mission critical, not just for the communications team. Having a developer available who can make it possible to have more than one photo on your page is as important as having someone who can shoot and edit the photos.

Communications teams should have developers baked in from the start, and not just for adding new features to the website. Having a developer on your communications team means you have someone who  an think about and build other artifacts to augment your message. A developer might think to host your website’s code on GitHub, allowing other developers to learn from it and offer feedback, or build an app to go along with a new initiative the team is rolling out, or identify and fix usability problems with some existing piece of the site.

What your website is made of and how it works speaks volumes about your organization, both internally and externally. Internally, it makes your communications team a “yes first” team, or at least one where the reason for saying no to, say, putting more than one image on a page, is a communications one, not a technical limitation. And when there is a technical limitation, you can realistically evaluate whether it’s possible to overcome it.

This doesn’t mean fire your entire comms team or only hire developers, nor does it mean hiring one developer will be your silver bullet. Instead, focus on fostering your team as one that is equal parts traditional communications and software development. Build a team ready to say yes to what your organization needs and not dependent on some piece of technology nobody understands.