Development Workflow
This week GitHub released some great new features. The new review feature finally makes code review a first class member of GitHub's feature set. This is one of the final bits we wanted for our build process at work.
I've blogged about bits and pieces of our workflow, but this week I'm going to outline the entire process end to end.
All our developers use a 'branch and pull request' model. Every change or new feature is developed on its own branch in our git repository. No developer can commit their changes to the main branch. They can only submit a pull request to be merged into the main branch.
Any pull request can only be merged if:
- The build was successful on our CI server.
- The build passes PMD, EsLint, CheckStyle and FindBugs checks.
- The code has been reviewed and accepted by one other developer on the team.
This ensures two sets of eyes have looked at an approved every change. PMD and FindBugs provide static analysis for bugs and code quality issues. While EsLint and CheckStyle ensure our code meets a common set of formatting. We also check the code coverage numbers for every build.
When set up in GitHub. Our branch looks like this.
Now any pull request (PR) can only be merged if all the above is met. Here is an example PR where all checks passed but code review found one issue that blocks a PR from being mergeable.
If you are wondering about how these checks or process is implemented see some of my past posts:
Java: Code coverage with Gradle and JaCoCo
Migrating to Travis-CI from Bamboo
Updating GitHub Status from Bamboo