WordPress WebOps Spotlight: Creating a Culture of Efficiency with Peer Review

Pantheon has hundreds of agency partners that use the platform to build, launch, and manage awesome websites for their clients. Each of these partners has workflows that help their team collaborate efficiently and ship releases day in and day out. One of these great partners is Alley Interactive, an agency in New York that builds big websites for news organizations and large-scale non-profit institutions. We caught up with CTO Matt Johnson to discuss how Alley employs a peer code review process to keep their projects moving.

“The peer code review fits our company culture—we don’t have a hierarchy. Partners get code reviewed just the same as any other team member.”

—Matt Johnson, CTO, Alley Interactive

Image

The Process—Pull Requests, Peer Review, Continuous Integration

The Alley Interactive production team stands strong at 30 developers, most of them specialized in WordPress, with a few JavaScript and Frontend developers as well. Project teams often include four or more active developers. That means making sure everyone is comfortable working with everyone else’s code: no lone wolves or maestro/savants.

To maintain their agency code standards and prevent problematic or difficult to maintain code from being deployed, the team engages in a peer code review process via GitHub pull requests. Code is committed to a feature branch as work in progress, and then submitted as a pull request on GitHub for peer review.

GitHub’s pull request UI provides an ideal forum for this work: all changes are presented clearly, and the ability to comment is built-in. Comments can even be attached to specific lines of code changed. If something doesn’t meet the code standards, the developer pushes more changes to the feature branch, which are then automatically added to the pull request. Until the code is approved by another team member, it won’t be merged to master.

“We take our responsibility for the uptime and integrity of our clients' sites very seriously, and we built this process to honor that,” Johnson said. “It's improved our code quality dramatically, and we subject everyone in the company to it, including senior leadership.”

Alley also has developed an internal Node.js application to assist with Pantheon integration. While line-by-line code comparison is excellent for ensuring developers understand and approve of one-another’s code, new code must be staged on a development environment as well before deployment. Automatically staging changes as they are merged to master—also known as “continuous integration”—is a key productivity booster in that it spares developers from wrangling the development environment themselves, and allows them to validate their new code faster.

The helper app manages synchronization between a private GitHub repository dedicated to the project and the Pantheon site. When a feature-branch corresponds to a Pantheon Multidev environment, the Node app will automatically sync the code changes to that environment on Pantheon triggered by a post-commit hook. When a change is merged to master, the app syncs the changes to the Pantheon Dev environment.

This gives Alley the option to include a working website URL—e.g. branch1-project.alleydev.com—along with any pull request. The upshot: project managers and stakeholders can review changes early, and provide vital feedback before things are in final QA. It is also beneficial when developers need to demonstrate or debug a behavior or service interaction that is specific to the Pantheon platform.

These pull requests are made often and code reviews are intended to move quickly, sometimes several in a day. Developers don’t spend a lot of time with code “hidden” in a local environment, and merges to (and from) Master happen frequently, preventing large divergences from forming between developers or sub-teams in the codebase.

"This is continuous integration because we’re getting the code into Dev immediately. It’s seamless."

Simple JSON config files on the Node side determine what GitHub repository corresponds to which site on Pantheon, and allow Alley’s team members to specify directories and files to be excluded from the sync, as well as any additional build or assembly steps to perform before pushing to the Pantheon environment. The syncing action between the Node app and Pantheon happens over rsync, so Alley leaves the Dev environment in SFTP mode. They generate a single commit in the Pantheon dashboard based on the rsynced changes when it’s time to deploy.

All Developers Are Equal

Anyone familiar with Alley’s coding standards can perform a review, which makes for an efficient workflow and keeps roadblocks from slowing the team down. The lead developer is responsible for being aware of any special circumstances that might require additional evaluation, and serves as the deployment gatekeeper when necessary.

“Each project is different, but we’ve found the code review works wonderfully across the board. The lead developer can jump in if there’s any sort of unique situation.”

Lead times for the code review process can vary from a few minutes to a few hours, depending on the size of the code and when the pull request was generated. Only one colleague needs to review it, and the team knows to only review code written for a platform they know well.

“It’s really an honor code type of thing,” Johnson said. “If you don’t know x language very well, you don’t review that code. This ensures that our process is efficient, since the team member reviewing your code is well versed in how it should look and act. The code review is not an adversarial thing, but rather a learning experience for both the reviewer and the reviewee.”

The team uses the same process for working on sites that have already launched—everything is still validated and subjected to the code review. A feature change might require using Multidev, but a simple CSS update can usually be made directly against master, and then merged, committed in the Pantheon dashboard, and deployed.

Welcoming Clients to the Workflow

If the Alley Interactive team is working with a client that has their own dev team, they welcome them to participate in the workflow. “It’s the client’s codebase, so they can handle it however they want,” Johnson said. “But we often find that the client adopts our development process or asks us to review their code. We have a well-oiled machine for reviewing code, so we’re always happy to help, and we’re happy when our clients like our process enough to use it themselves”

Alley’s team directs all clients to make use of Pantheon if they need to collaborate, using their Node app to spin up a Multidev environment for the client. This environment gets continuous integration deployments to the GitHub branch just like any other environment, allowing developers from the client team to participate as peers in the Alley workflow.

“The main goal was to have a consistent workflow so our developers could look at the same Git repo, and always be on the same page.”

Advice to Other Agencies

Alley Interactive has certainly found the sweet spot when it comes to the workflow that best fits their team, but what about younger agencies and those just starting out? We asked Johnson what advice he’d share with other agencies trying to establish a synchronized process for shipping code and elating clients:

“Embrace a code review from day one. Just do it. And set up some sort of official QA testing right off the bat—this would have saved us a lot of problems and errors found by clients had we done it sooner."