From the Blogosphere
Efficiency in Development Workflows: Pull Requests and Code Review
We talk about the steps necessary to get your feature shipped: Pull Request, Code Review and Merging
By: Manuel Weiss
Aug. 30, 2013 01:00 PM
This is a republished blog post. You can find the original source here: http://blog.codeship.io/2013/08/22/the-codeship-workflow-part-2-pull-requests-and-code-review.html
Using Pull Requests
Open pull requests are helpful as everyone can see what we are working on. One really important part of feature branches and pull requests are proper commit messages.
Writing good commit messages
I personally prefer git-gui for commiting and splitting up commits. It does only this job, but it does it very well. Take a look at some of the other git tools we like at the end of the post.
Using GitHub Issues and Labels
Now that we assigned the pull request, somebody on our team has a GitHub issue with his name attached. This way anybody can easily filter out the pull requests they need to look through. Now the last step is labeling the pull request with needs review. This way the reviewer knows this pull request is finally ready to reviewed.
When starting a pull request, the developer and reviewer can decide on looking through the pull request together or not. Especially for large changes reviewing the code as a pair is great.
Then we review the structure and syntax of the code, but we currently do not review the functionality itself. Before implementing a feature we discuss it in detail, so there is a common understanding. Once the feature is implemented, we trust our engineers that it does what it should. We are not working with a staging system.
One improvement we are starting with now is functional reviews for large and public facing features. Just so a second pair of eyes looks at changes that possibly impact a lot of our users. But this is still not a strict part of our workflow. A developer may request it after the implementation or we plan it before we start working on it.
When the review is done it either gets merged or, if the reviewer leaves comments, the GitHub issue is labeled as reviewed. This way developers can take a look at their open issues and see which have been reviewed and which need more attention.
The feature is ready to be merged as soon as the developer either updates the pull request or explains why she did it differently.
There's one challenge with every release workflow that involves code reviews: Getting the team to review as fast as possible without interrupting their work. We try to do it asynchronously for smaller features and sitting down for shared code review on larger features. This is no silver bullet, but in our experience it works well.
GitHub Merge Button
The only exceptions are scheduled releases, for example a maintenance Deployment. Then we let somebody review the changes and leave a ready to be merged comment. The build can then be merged whenever the developer wants.
By releasing through the GitHub merge button everyone on the team can push to production. Making this possible for every developer or designer in our team is very valuable. It allows everyone to take part in the process and it speeds up our daily work.
As soon as we hit the merge button our tests are kicked off on the Codeship again and the deployment starts. Next time we will go into more detail about this part of our infrastructure, how we deploy to our staging app, test our migrations, build our deployment pipelines and then push to production several times a day.
Your Development Workflow
Ship long and prosper.
Latest Cloud Developer Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week