March 15, 2022
Getting new software releases out efficiently and effectively is not easy. There are a lot of moving parts and if your entire team is not aligned perfectly, you can often run into unforeseen challenges that can slow and even derail your entire development schedule. This is especially the case when it comes to pull requests. If you aren’t covering your bases effectively here, you’re not going to achieve the efficiencies that you need. Some of the common questions that come up often are as follows:- What else do we have to consider when merging the pull request?
- Do I need to update the user documentation?
- Am I expected to tag the commit for a release or not?
All of these point to potential errors that can be made if you don’t have a systematic process to work through. That’s where checklists can be so powerful - helping reviewers to avoid errors of omission and ensuring that standards are maintained time and time again.
What We’ve Learned About Checklists
We set out to integrate checklists into our development process and naturally, it went through a number of iterations. The first version included a standard template for our internal release page that reviewers would have to work through before merging. This was a good start but the core weakness was that the checklist was decoupled from the specific pull requests, meaning that you would have to link it explicitly in order to connect the two.
So, we tried then to integrate the checklist by copying each point over as a task into the pull request. This was definitely an improvement because it was actionable and it created the necessary follow-up tasks where needed. However, it was still quite an inflexible process and it didn’t’ give us the agility that we were looking for.
We needed something leaner, more flexible, and easier to track. The checklist needed to adapt based on the contest, while still enforcing the changes with a merge check in order to secure our compliance. To give you a sense of how the context changes the required components, here are just a few of the types of pull request tasks that we were incorporating:
An additional benefit to doing it like this is that our checklists can evolve over time, taking into account lessons we learn along the way. We can see exactly when, who, and what has changed and we can copy just one file across to all the other repos, so we can compare code easily.
How Pull Request Checklist Buddy for Bitbucket Can Help
We took everything we learned from our experiments and created an application that we think can really be useful for development teams. Bitbucket’s core functionality doesn’t include flexible default tasks, and so our application steps in to leverage the power of checklists in a flexible and contextual way.
When you use our tool, you’ll find that you get a much more holistic view of what’s going on in your code and you can sustain your standards across teams, projects, and the entire organization.
If you’d like to try the application for yourself, check it out here. And we’d love to hear feedback on what you think. We hope that it will make your release processes a lot easier!