It's no secret that at Lullabot, we love GitHub. We use it for as many projects as possible, and have found some great success with the tools it provides. They've helped us simplify development, code review, documentation, and even communication and transparency with our clients.
Our typical process for Drupal project begins with of a checkout of our Drupal Boilerplate (thanks Eric Duran!). It gives us a base directory structure to start from, some basic drush commands, and drush aliases to simplify deployment tasks. From there, we commit Drupal into docroot and start to build out the site as normal.
Next, we input the projects requirements into the GitHub issue tracker. These take various forms for different clients, depending on whether we're starting from user stories, visual design assets, or actual written technical requirements. After we have a decent backlog of tickets, we prioritize them with the client and group them into milestones. Those milestones are typically set up as two week sprints, and each ticket will typically get its own branch of code.
When a ticket is ready for review, the issue can be turned into a pull request with a nice command line tool called hub. Pull requests are an effective means of performing peer review on code before merging into your stable branch. If one developer sends a pull request, another reviews the code before it's merged with the project's master branch.
While the peer review process is something we do for our own sanity, quality control, and knowledge sharing, it's rarely a process that clients can participate with. When the client is technically savvy and has time to work with us on that level it's great, but it's not something we can count on with every project.
A solution we've found to address this is to leverage the power of GitHub and to add some Jenkins magic into the mix. By tying GitHub's webhooks into a Jenkins instance, we can turn the changes for each pull request into a fully testable Drupal environment. This allows the client or a reviewer to click around a fresh QA site, test the features that would be affected, and easily approve or deny those changes. They don't have to manually push code to a QA environment, or worry about stepping on other in-progress features in the process. The site they're testing is completely dedicated to the changes within that feature's branch, and it's extremely productive as a result.
If you'd like to skip ahead to the geeky details, dive right into the GitHub repository. Otherwise, you can stick around for an overview of how we did it.
The process goes something like this:
- A new Pull Request is created.
- Jenkins detects the Pull Request, creates a new Drupal instance, and applies the Pull Request to the new instance.
- Jenkins posts back to the Pull Request on GitHub with a comment about where the new environment can be found.
- Once the Pull Request is merged, you can tell Jenkins to delete the environment, and it can then post a comment to that effect.
There are other commands you can access by posting to the pull request's comment, such as asking the bot to please rebuild (such as after a new commit), and it will also post to the thread if a build fails.
This process has really helped in our projects to streamline peer reviews. Here's what a client had to say about the process:
"The pull request environments have been a huge help in testing and validating the features or bugs for our sites. We are able to isolate an issue and validate it on a functioning site before final testing and deployment. It has also made our development practices clear, since you know what you're committing code to and testing against." — Mike Shaver, Intel
Overall this tool really saves Lullabot a lot of time, which saves our clients money. We've open-sourced the project on GitHub and would love to hear what you think of this. If you find it useful, but don't have the expertise to set it up, give us a shout and let's talk about how we can help you.