Checklists for improving the development process, part three: adaptations of the checklist for creating pull requests
In my last two blog posts about checklists I have presented some checklists for handling pull requests and described their effect and the team’s reaction. I have also stated that checklists continuously need to be altered and adapted in order to be truly helpful. In this blog post I am going to explain which changes I have made to the checklist for creating a pull requests and what were the motivations behind that.
Alterations and adaptations of the original checklist
Putting the checklists on trial in our real world workflow revealed several shortcomings and flaws in them that needed to be fixed. For example, I soon discovered that even though it leaves the programmer more freedom at going about his tasks, the list for creating pull requests did not work out as a do-confirm list. The process turned out to be more complex than I had at first imagined; for example, it is important that the latest master is merged into the branch before running the _common solution gulp task on the latest _common master branch, otherwise running the gulp task would propagate changes into my branch that are already in the master branch. So I changed the checklist into a read-do list.
Another thing I realized was that it was impossible to use one and the same checklist for creating pull requests for a regular branch and for a hotfix branch. The list requires us to merge the master branch into our branch, but a hotfix branch will end up in the production branch, where the master branch should by no means end up! So I created a separate list for dealing with hotfix branches, and added some more steps to it.
Moreover, having a look at our application’s unit tests made me add a further step to the checklists. Many of the tests failed because they had not been run for quite some time. Adding the step ‘run tests and make sure they succeed’ to the checklists, I hope that in the future the tests will be used more frequently. This will not only ensure that the tests are always up-to-date, it will also help us discover bugs our new changes would have introduced to the system.
So, this is the updated version of the checklist for creating pull requests:
Since it had been me who ended up fixing all the broken tests, I am especially happy to see that the team members carefully follow this new step ‘run the tests …’ 🙂