Automated Pull Requests

Goal

The goal of this project is to eliminate the human step required in ensuring pull requests contain quality code, and have a Build Server do building and testing of pull requests. The build server (TeamCity) will then interact with the repository host and approve or reject the pull request based on the build results. This will prevent broken code from being pushed into the main branch, and ruining the team's productivity.

Background

Pull requests are an important piece of the development process. When a developer has finished work on a particular feature, they create a pull request to merge that feature into the main source control branch. This pull request is then reviewed by the developer's teammatea who provide feedback on the code. When they approve the Pull Request, it is merged into the main branch of the codebase, and available for the rest of the team to code against.

In a perfect world, before submitting the pull request, the devloper builds the entire project, and makes sure all of the automated tests pass successfully. In a perfect world, the devloper that is reviewing the pull request pulls down the source branch to their local repository, builds the code and runs all the tests as well. In practice, both of these steps rarely followed for all the code in the codebase.

For example, when you are developing a web application, a database must be built and deployed, then the web-application has to be launched and smoke tested - because some errors only happen at run-time, not compile-time. This process can take up to 15 minutes. To save time, developers will skip this build and testing step and complete the pull request. If someone missed something, the build could break, and everyone's work is interrupted because they can't develop against broken code. In many teams, this will earn you a token of appreciation for interrupting everyone's work: