How we use Github to release quality code at Fusion

This post was published by the Fusion tech + product team, and not the Fusion newsroom.

Let’s say, hypothetically, that you’ve just started a job on the product team at a hot new digital media company. No, not that one. And no, not this one either.

Anyway, you’re freshly returned from the first team meetup, and ready to push some code. What next?

As a seasoned developer (more Sriracha than salt), you’ve already got a local development environment backed by the VIP Quickstart repository. Your product manager has a nicely groomed Trello ticket ready for development, UX has added the design and interaction notes.

A well-groomed card in Trello. Cards usually represent  2-5 days of effort.

A well-groomed card in Trello usually represent 2-5 days of effort.

Now – let’s make some web!

1. Create a feature branch

Fixing a bug? Make a new branch!

Adding a feature? Make a new branch!

Changing a style? Make a new branch!

ALL changes to our codebase get put into a branch first. This lets us see specifically what is being changed within a project, and be intentional about what ends up in master.

How do we name branches? We follow this pattern: (number of original Github issue)-followed-by-keywords-describing-the-project. Using this pattern makes it easy to locate branches when there could be dozens in development at once, and later in the process, this branch name is what we’ll give product managers so they can checkout the work to our staging server and vet the design and functionality before release (we use a homemade tool called Git Switch for this).

We built a small plugin for WordPress that makes it easy to switch git branches on a development server. It's open source, natch.

We built a small plugin for WordPress that makes it easy to switch git branches on a development server. It’s open source, natch.

2. Write commit messages

As you’re changing code, be deliberate about commit messages. Use the commit title to describe the technical aspect of the change. We’ve all done personal projects where the repository ends up looking like this:

Don't write commits like this.

Don’t write commits like this.

But doing this in a team environment would classify either as a grave sin, or a stellar troll. We want to be sustainable with our development practices, which means that our production code is abstracted, well-documented, and peer-reviewed. Here’s the type of commit message we like to see in the log – it explains why and what.

3. Publish the pull request

After you’ve got the feature built, or the bug squashed, or the design implemented, then it’s time to publish the pull request. Some development shops will use Hub to create a pull request from the original Github issue, but we prefer a separate pull request because occasionally a specific Github issue is targeted over multiple branches (see that screenshot above).

The description of the pull request should describe the work and include before/after screenshots. The description should also link to the Github issue and Trello cards associated to the work.

By the time you’ve add all that to the pull request, your first run of tests on the Github-connected Travis website will have probably completed. You had a good feeling they were going to pass, as you ran phpunit and jasmine locally before pushing the branch, but it’s always nice to see those green checkmarks light up.

Living dangerously is committing your code without knowing if your test will fail.

Living dangerously is committing your code before knowing if your test will pass.

4. Go through code review

Let’s recap. You’ve done the deed and pushed your branch to Github to start a new pull request. All tests passed. It’s time to deploy this bad boy.

Except, not quite yet. All code pushed to production goes through at least one code review at Fusion. We’re using VIP’s coding standards, but that’s just the start. When doing code review, we aren’t just checking whether the minimum requirements were met. We are checking whether the spirit of the task was completed; whether the code looks as clean on the inside as the UI/UX does on the outside; whether the release meets our basic criteria of simply not sucking.

Code review ranks at the top of our important team practices list – it’s the form our quality control takes, and also one of the best ways to learn and grow with a codebase.

How do you initiate code review? Just comment on the PR something like this:

If you see something, say something (or even better – make a pull request).

If you see something, say something (or even better – make a pull request).

Good code review entails understanding someone else’s code fully. WordPress VIP has guidelines on what they look for, some of which are environmentally dependent, but code review is a strategy that adds value to any collaborative engineering effort. The net result of code review is cleaner, more performative code, and a team that learns from itself while also keeping current with what other people are adding to the codebase.

5. Merge the branch into master

Last step. Now that you’ve got a pull request just raring to go, let’s merge into master. Of course you don’t have any merge conflicts, because you’ve been merging master throughout the development process. No surprises here! As master is merged, the update is also pushed to the Automattic-managed SVN that backs VIP.

Voila. That’s it. A Slack message enters the client, heading straight for the #deploys room:

Not yet built: A keg-bot to pour drafts when we deploy.

Not yet built: A keg-bot to pour drafts when we deploy.

You’ve just released your first quality feature to Mazel.

This process isn’t foolproof. We still make mistakes and occasionally ship bad code into production. But this process makes us more mindful about quality, and you can bet your ass that we remember our mishaps.

Want to build quality digital media products? Check out our available positions. We’re ramping up the Fusion tech + product team in 2015.