Pull Requests & Code Reviews
Pull requests let you tell others about changes you've pushed to a branch in a repository on GitHub. Once a pull request is opened, you can discuss and review the potential changes with collaborators and add follow-up commits before your changes are merged into the base branch.
It's important to create a pull request when you're ready for your code to be reviewed and merged into the main branch. This allows other team members to review your code, provide feedback, and ensure that the changes are in line with the project's goals and coding standards. Usually, a pull request will be reviewed by at least one other team member before it is merged.
Before creating a pull request, make sure that pipeline tests are passing.
Creating a Pull Request
When you are ready to merge your changes into the main branch, you can create a pull request on Bitbucket. There's a Pull Request template that you can use to provide information about the changes you've made and any additional context that might be helpful for reviewers. It's important to fill out the template as completely as possible to ensure that your pull request is reviewed quickly and efficiently.
Let's see the fields that you need to fill out in the Pull Request template:
| Field | Description |
|---|---|
| Title | A short, descriptive title for the pull request. This should summarize the changes that are being made in the pull request. |
| Description | A detailed description of the changes that are being made in the pull request. This should provide context for the changes and explain why they are necessary. |
| Demo | A screenshot, video or any other relevant document of the changes that are being made in the pull request. This can help reviewers understand the changes more easily. |
| Asana Task | The Asana task that this pull request is related to. This should link to the Asana task that describes the work that is being done in this pull request. There should always be an Asana task for every pull request. |
| Deployment Plan | A description of how the changes in this pull request will be deployed to production. This should include any necessary steps or considerations for deploying the changes. Usually this is not necessary for most of the pull requests and the default value can be used. |
| Fallback Procedure | A description of the fallback procedure in case the changes in this pull request cause issues in production. This should include any necessary steps or considerations for rolling back the changes. Usually this is not necessary for most of the pull requests and the default value can be used. |
| Changes in the user's help pages | A description of the changes that need to be made in the user's help pages. Usually this is not necessary for most of the pull requests and the default value can be used. |
| Changes in the on-premises administrator manual | A description of the changes that need to be made in the on-premises administrator manual. Usually this is not necessary for most of the pull requests and the default value can be used. |
| Changes in the disaster recovery plan | A description of the changes that need to be made in the disaster recovery plan. Usually this is not necessary for most of the pull requests and the default value can be used. |
When creating a pull request, remember to check the delete branch after merge option. This will automatically delete the branch after the pull request is merged, keeping the repository clean and organized.
Asana Task
As mentioned above, every pull request should be related to an Asana task. This helps to keep track of the work that is being done and ensures that all changes are properly documented. When creating a pull request, you should link to the Asana task that describes the work that is being done in the pull request. This allows team members to easily find more information about the work that is being done and provides context for the changes that are being made.
On the Asana task, you should also link back to the pull request that is related to the task. This creates a bi-directional link between the Asana task and the pull request, making it easy to navigate between the two and ensuring that all changes are properly documented.
There should be an automation in place that automatically creates a link between the Asana task and the pull request if the Asana task link is added in the pull request description. This automation is quite new and may not work as expected. If you find any issues with this automation, please report it to Aleix.
Code Review
Once you have created a pull request, other team members will review your changes and provide feedback. It's important to be open to feedback and willing to make changes based on the feedback you receive. Code reviews help ensure that the changes are in line with the project's goals and coding standards and that any potential issues are caught early in the development process.
When reviewing a pull request, team members will look for a number of things, including:
- Code Quality: Is the code well-written and easy to understand? Are best practices being followed?
- Functionality: Does the code work as expected? Are there any edge cases that need to be considered?
- Security: Are there any security vulnerabilities in the code? Are best practices being followed to ensure the security of the application?
- Performance: Is the code efficient and performant? Are there any optimizations that can be made to improve performance?
- Testing: Are there tests in place to ensure that the code works as expected? Are there any additional tests that need to be added?
- Documentation: Is the code well-documented? Are there any additional comments or documentation that need to be added?
Please, make sure you provide a demo of the changes in the pull request. This can be a screenshot, a video, or any other relevant document that helps reviewers understand the changes and verify more easily that the changes work as expected.