Database Projects – Working with Pull Requests
In one of the previous blog posts, I described how to merge branches manually (Database Projects – Merging changes). When merging manually, there is no way to revise the development that someone did. If you want to start with peer reviewing during the development process, you can easily do so by using Pull Requests.
Quick Overview
- What is a pull request?
- How to create a Pull Request?
- How to review a Pull Request?
- How to approve a Pull Request?
- How to reject/disapprove a Pull Request?
What is a Pull Request?
A Pull Request is an alternative way of merging branches. Instead of executing the merge yourself, you will create a Pull Request for someone else to revise your development and approve and merge when ok. By doing this you are introducing peer reviewing into your development process. From my experience, using Pull Requests will improve your development quality since someone needs to validate your changes before they can be deployed to a certain environment.
I wouldn’t advise using Pull Requests to get changes in a development environment but I would advise using it to get changes to an Acceptance- or Production environment. By doing this, you can already find issues in an earlier stage than in production.
How to create a Pull Request?
To navigate through the process of creating a Pull Request, I have created a Database Project called DemoProject and linked it to Azure DevOps. I have made a change in my feature/dwh-1 branch and now I want to get this change into my master branch(often called the main branch as well).
To create a Pull Request in Azure DevOps, you need to navigate to your Repository, in my case I will be using my DemoProject Repository in my DatabaseProjectDemo Project.
As soon as I navigated to my repository, I can go to Repos (on the left) and choose Pull requests. By doing this I will get an overview of active Pull Requests and the option to create a new one as well.
Now, we click on the “New Pull Request” button and we are ready to create our Pull Request. As a first step in the process, we need to choose which branch we would like to include in the Pull Request. In my case, this is the feature/dwh-1 branch. As a second step, you need to make sure to select your target branch, which in my case is master at this moment.
As soon as you have selected the source branch and target branch you will get a more extended form where you can give a title and description to your Pull Request, and assign who needs to review your work. If you’re using Azure DevOps Boards, you can also link the development ticket.
As soon as everything is setup properly, you can hit the Create button at the end of the form
As a result, we can see the created Pull Request:
If we take a closer look at the created Pull Request, we can see at first that the Pull Request received the status “Active”, meaning that it isn’t reviewed yet. What we can see as well is that “No merge conflicts” were found. When you create a Pull Request, Azure DevOps is going to check if there might be merge conflicts, if there are it will be shown clearly. In that case, you’ll need to handle the merge conflicts first.
How to review a Pull Request?
When a Pull Request (PR) is assigned to you, you can easily open the Pull Request by navigating to the Pull requests screen as mentioned above and clicking on the specific Pull Request. As soon as you have opened the Pull Request, go to Files and you can start reviewing.
As you can see in the screenshot above, a change was made to the DimProductCategory.sql file. A column called DutchProductCategoryName was added to the SQL file.
How to approve a Pull Request?
The approval process in Azure DevOps is very straightforward. To approve a Pull request we just need to click the Approve button on the top right corner and as soon as we have confirmed, the Complete button will appear next to it. To finalize the Pull Request we just need to click on the Complete button.
By hitting the complete button, the merge between the feature/dwh-1 branch and the master branch will be executed as soon as we click the complete merge button.
As soon as we have confirmed, the status of the Pull Request will change to Completed.
As soon as the status changes to Completed, our feature/dwh-1 branch will be deleted automatically as well. By using Pull Requests, you are avoiding a lot of manual branch maintenance.
How to Reject/Disapprove a Pull Request?
To show you how to reject a Pull Request, I have created a new branch feature/dwh-2 where I added a new column into the DimProductCategory.sql file. Due to a mistake, I made a typo in the column name. In this case, my colleague can do 3 different things.
- Let me know that I introduced a typo, and make me adjust it before approving the Pull Request.
- Reject the Pull Request and inform me of the reason why it got rejected in a comment. By using Reject, you give clear feedback that the changes are not ok.
- Use the Waiting for Author, which is a more friendly way to inform the Pull Request creator that there are some adjustments to be made.
To give this feedback on the Pull Request, you need to navigate to the top right corner on the Pull Request and use the downward arrow next to Approve.
As soon as you have selected your choice, make sure to add a comment on the Pull Request as well to explain why you have chosen that specific status. Import to know is that as long as the status remains on “Wait for author” or “Reject” the Pull Request can’t be completed.
In my example, I have chosen to set the feedback status to “Wait for author”. This will block other approvers to complete the Pull Request (if you have provided multiple approvers in the Pull Request). Now I want to provide my feedback to the developer by adding a comment on the Pull Request.
As soon as the typo has been resolved, the Pull Request creator can go to the comment and hit the “Resolve” button.
Nice article Olivier! Maybe you could also mention the squash commit, which produces a clean main branch.