How I enhance pull request quality on GitHub and Azure DevOps

Code reviews and PRs are deservedly known as a fantastic way to improve code and product quality.

I find that having a checklist is super handy for remembering all the checks to perform and the context to give a reviewer.

Adding a template to your platform

On some repository and CI platforms you can automatically populate the description field of a PR with content to remind yourself what to consider for each review.

You’ll need to check your the instructions for your specific platform but in general it means adding an .md file to a specific directory. For example:

Platform Location
GitHub docs/
Azure DevOps /docs/pull_request_template/

My pull request template in markdown format

Here’s the checklist I use. Is there anything you would add or remove??

# Summary

- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] This change has database scripts

_Describe the specific issue this is fixing, just a summary will do if there is a link back to the work item that this change addresses._

# What has changed

_Summarize the change made e.g. Small change - added new UI element, wired it up to existing data model._

## In scope areas

_Specify the specific areas of code or modules that have been affected by this change. e.g. frontend only, backend only or ticketing module and authentication module._

## Out of scope areas

_List any areas that could usually be assumed to have been changed but are not in this case. The point is to save the reviewer and tester time._

# Risk

_Describe the risks that apply to your application. This will be very specific to your business but some of the common risks are_

- [ ] Does not use our gradual release process
- [ ] Handles PII that needs to be compliant with GDPR requirements
- [ ] Adds new libraries
- [ ] Third-party apis (dependency must be resilient)
- [ ] Requires specific access control (e.g. admin only functionality)
- [ ] Handles money amounts
- [ ] Has specific OWASP security concerns([](

# Author pre-publish checklist:

- [ ] Has relevant logging
- [ ] Meets our coding standards (link*to_your_coding_standards) - \_Prefer auto-linting for this if possible*
- [ ] I have performed a self-review of my own code (link_to_standards)
- [ ] I have added tests that prove my fix is effective or that my feature works
- [ ] New and existing unit tests pass with my changes
- [ ] There are no obvious injection issues
- [ ] User input is validated
- [ ] No PII is stored to logs
- [ ] My changes generate no new warnings
- [ ] I have sat with a tester to demo and discuss the change
- [ ] Relevant authorization checks are implemented
- [ ] I have made corresponding changes to the documentation

# Developer testing performed

_Describe the testing you have performed as part of this change. Note it here for the reviewer and tester. Note if there is any data or scripts required to set the system up correctly to test your feature._

_Is there any testing that seems like it would be needed in this case but maybe isn't required? - note it here with reasoning for the reviewer and tester_

# Reviewer checklist

- [ ] All the risks above are not present or have been mitigated


Using a template might seem like too much bureaucracy but it is really helpful when you have some place to add issues that regularly show up in pull requests. This helps the author fix them before wasting anyone’s time.

The pull request template ensures that everyone has enough context to work with the new code before it is merged (e.g. testing).

The pull request template is incredibly useful for new team members to understand the level of quality required by your organisation and to show them what is currently important. e.g. if you are doing a gradual system wide refactor and don’t want anyone to use the “old way” of doing something but there are still many example of the “old way” in your code base, the code review template can be used to show the new team member that they shouldn’t use that technique any more, even if they see it everywhere.

You can remove things from the pull request template when the is no longer relevant (and add them back again if the issue starts showing up too often). It is a living document that supports the developers on your team.

The code review template provides a nice list of the things that could be automated away in your org. You should be on the lookout for ways to add a CI step or a pre-commit hook to automate the check away. These make for great hackathon problems!

Darragh ORiordan

Hi! I'm Darragh ORiordan.

I live and work in Sydney, Australia building and supporting happy teams that create high quality software for the web.

I also make tools for busy developers! Do you have a new M1 Mac to setup? Have you ever spent a week getting your dev environment just right?

My Universal DevShell tooling will save you 30+ hours of configuring your Windows or Mac dev environment with all the best, modern shell and dev tools.

Get DevShell here: ✨

Read more articles like this one...

List of article summaries


Extract user profile attributes from an Azure ADB2C tenant using the Microsoft Graph API

I had to retrieve a list of users from an Azure Active Directory B2C instance today. I thought I could just go through the Azure UI but that’s limited to short pages of data and limited attributes.

There is a CSV export provided on the UI but you won’t get the required identity objects in the csv output if you need a user’s signin email address.

I had to use the Microsoft Graph Api to get what I needed. This is a bit hacky but it does the trick!


Force restart your Azure App service site and host

Sometimes your Azure App service host will need to be restarted. You can do this but it’s hidden away in the Azure resource manager site. Here’s how to find it!


Scheduling a feature toggle using no-code with Azure Logic Apps

I use launch darkly to toggle features on an app. There is one third-party dependency that has regular scheduled maintenance and I need to toggle the feature on and off on schedule.

Launch Darkly has built in scheduling to handle this scenario but you have to be on the enterprise plan to use it. The enterprise plan is too expensive to upgrade to for scheduling alone so I needed to find a different way to automate this.


Avoid rebuild of React App in every CI stage

If you have a react app you can use env vars like REACT_APP_MY_ENV_VAR in your application and React will automatically pull them in to your app when you build the production application.

This is very useful but if you have variables that change for each environment and your application build takes a long time, you might want to avoid building unnecessarily in CI. For example you might have a QA environment and a Staging environment that have different configuration.

We type-check our code on each build and that was taking 5 minutes+ to build each environment so we had to make it faster. We changed our app from using REACT_APP env vars to using a configuration file that we could quickly write to using CI.

Our CI system is Azure DevOops so the CI scripts here are specifically for Azure DevOps but they apply to most CI systems with small changes.

The real work happens in a Node.js script that would work anywhere.