DEV Community: Marcelo Sousa

Automate pull requests with GitHub Starter Workflows

Marcelo Sousa — Thu, 27 Oct 2022 21:24:41 +0000

This guide shows how you can set up GitHub workflow templates to automate common GitHub pull requests workflows!

The Problem

Every time a new repository is created in our GitHub organization, we need to ensure that it starts with a set of common pull request automations.

In the past, this meant that we needed to install multiple GitHub actions.

We were copying the GitHub action YML configurations from other repositories and then customizing it for the newly created repository.

This process was fine but it is error-prone and not very scalable because we need to maintain and customize multiple GitHub actions.

The Solution

Many GitHub repositories already use the .github folder to host workflows and templates for pull requests.

GitHub provides the ability to share the files across all the repositories in an organization in the special .github repository.

This means that we can create a .github repository in our organization and then add the GitHub actions that we want to share across all the repositories.

GitHub calls these starter workflows.
A starter workflow could be used to easily add workflows to the newly created projects.

This solves our problem of copying YML configurations between repositories but we need to create one starter workflow for each pull request automation.

So, we've decided to use Reviewpad as a single source of truth for all the pull request automations.

This way, any repository can get these automations with a couple of clicks.

The Setup

We will use Reviewpad to show case starter workflows.

To do that, we will need two steps:

Add the Reviewpad configuration with the specification of the automations
Add the Reviewpad starter workflow to the .github repository.

Step 1. Specify the pull request automations in Reviewpad

We started with the following list of automations and checks:

Label pull requests based on their size
Check that the pull request commits come after one another (i.e. they have a linear history)
Check the commits messages against the conventional commits specification
Check the pull request title against the conventional commits specification (this makes sense because we squash and merge certain pull requests)
Warn pull requests that do not have an associated GitHub issue
Add a comment to pull requests if their description was empty
Greet users on their first pull request

These can be configured in Reviewpad in a few minutes.

api-version: reviewpad.com/v3.x

labels:
  small:
    color: "#294b69"
  medium:
    color: "#a8c3f7"
  large:
    color: "#8a2138"

workflows:
  - name: add-label-with-size
    always-run: true
    if:
      - rule: $size() <= 30
        extra-actions:
          - '$addLabel("small")'
      - rule: $size() > 30 && $size() <= 100
        extra-actions:
          - '$addLabel("medium")'
      - rule: $size() > 100
        extra-actions:
          - '$addLabel("large")'

  - name: lint-commits
    always-run: true
    if:
      - rule: '!$hasLinearHistory()'
        extra-actions:
          - '$warn($sprintf("The pull request it outdated with the base @%v", $base()))'
          - '$fail("Pull request is outdated")'
      - rule: 'true'
        extra-actions:
          - '$commitLint()'
          - '$titleLint()'

  - name: check-for-linked-issued
    always-run: true
    if:
      - '!$hasLinkedIssues()'
    then:
      - '$info("This pull request does not have a linked issue")'

  - name: first-time-contributor
    always-run: true
    if:
      - '$pullRequestCountBy($author(), "all") == 1'
    then:
      - '$commentOnce($sprintf("Welcome @%v! Thank you so much for your first pull request!", [$author()]))'

  - name: empty-description
    always-run: true
    if:
      - $description() == ""
    then:
      - '$warn("The description is empty. Please add more information!")'
      - '$fail("Empty description")'

Add this file to your organization .github repository so that it can be referenced later in the Reviewpad GitHub action.

For more information about the Reviewpad configuration, check our documentation.

Step 2. Add the Reviewpad starter workflow to the `.github` repository

The Reviewpad starter workflow is a GitHub action that will run Reviewpad as a GitHub action on every pull request.

To add a starter workflow, you need to add two files to the .github repository under the folder workflow-templates.

The first file reviewpad_action.yml is the Reviewpad GitHub action that will be installed in the repositories.

name: Reviewpad

on: 
  pull_request_target:
    types:
      - opened
      - synchronize
      - edited

jobs:
  reviewpad_job:
    runs-on: ubuntu-latest
    name: Reviewpad
    steps:
      - name: Reviewpad
        uses: reviewpad/action@v3.x
        with:
          # Uses a default Reviewpad configuration file to get your started.
          # For customization and documentation, see https://github.com/reviewpad/action
          file_url: [URL-TO-REVIEWPAD-CONFIGURATION]

Note that you should update file_url parameter to point to your organization configuration file.

The second file reviewpad_action.properties.json is the metadata file that specifies the starter workflow.

{
    "name": "Reviewpad Starter Workflow",
    "description": "Reviewpad starter workflow.",
    "iconName": "reviewpad-icon"
}

If you want to add the Reviewpad logo to the starter workflow, add the icon to that folder.

The Demo

You can check the demo in the original post on Reviewpad's blog here!

If you liked this post, join our community on Discord to keep learning new ways to save time in pull requests.

And, if you to get more features out of Reviewpad consider installing the GitHub Reviewpad App.

PS: Support our project on GitHub with a star!

Modern Trunk-Based Development

Marcelo Sousa — Mon, 17 Oct 2022 13:35:43 +0000

For the old guard software developers, trunk-based development is the way to go. For younger developers, used to GitHub pull requests, it is unlikely that they know what trunk-based means. This article shows how we use automation to combine TBD principles with pull requests and get the best of both worlds.

Trunk-based development (TBD) is a software development methodology where the developers continuously merge changes into a single long-lived branch.

Two benefits of TBD stand out:

TBD avoids branches which save developers’s time from merge hell situations;
TBD fosters small atomic commits which are essential to build loosely-coupled systems where a developer has the ability to change one part of the system without impacting the rest.

For engineering leaders, TBD seems a no brainer and Google’s State of DevOps Report has consistently associated TBD with a higher software delivery performance.

At the core, TBD fosters an high-trust and low-blame cultures which tend to have higher organizational performance.

However, one of the surprises of the 2022 State of DevOps Report is that trunk capabilities had a negative impact on software delivery performance.

What changed?

According to the report, the number of respondents in the study with 16+ years of experience decrease from 40% to 13%.

Developer experience is a key factor to implement and benefit from TBD practices.

The report mentions that this difference is likely due to the additional practices required to successfully implement Trunk-based development. These additional practices can be resumed to a robust Continuous Integration (CI) mechanism that ensures that the trunk/main branch is never broken.

A different perspective

Over the past years, we have also seen a decline of interest in TBD when we interviewed developers with less than 10 years of experience. However, we observed that the main reason is not related with the lack of a robust CI but with the adoption of git-based version control systems like GitHub, GitLab and Bitbucket.

These version control systems naturally force developers to use feature branches and asynchronous collaboration via pull requests. There are many junior developers that never heard of TBD.

We also found that teams that rely heavily on feature branches and pull requests typically have strong CI mechanisms to ensure that the pull request merge does not break the long lived branches. In fact, GitHub Actions or GitLab Pipelines simplify the process to quickly get a basic automated CI system up and running.

Pull requests as a git merge blocking mechanism is necessary in low-trust environments found in open source projects where you have contributions from untrusted parties.

Teams practicing TBD understand that it doesn’t make sense to generalize this reality to a team of software developers where high-trust, low-blame culture is key.

The best of both worlds

We see pull requests as a useful mechanism to automate, document and audit three tasks:

Execute a set of automated tasks, e.g. build, tests, code analysis;
Code review;
Git merge approval.

We believe the adoption of pull requests will increase in the future for security reasons. For example, a two-person reviewed requirement must be fulfilled for a team to reach level 4 of the Supply chain Levels for Software Artifacts standard.

We found that teams doing TBD find it hard to adopt pull requests because it creates a lot of friction in their processes.

Reviewpad started from the observation that not every pull request is the same.

This fits nicely for teams updating their TBD practices to use pull requests.

For example, a pull request that introduces a database migration is very different from a pull request that performs a minor refactoring of the code. In the first case, it makes sense to have a more in-depth code review and testing procedures to ensure the correctness of the migration.

At the moment, you can enforce pull request workflows to deal with this separation of concerns using the GitHub Reviewpad Action.

To install it in your repository you just need to add two files:

The GitHub Action YAML file that lives in the .github/workflows directory.
The Reviewpad YAML file that specifies the pull request rules and automation workflows. This file is read by the action to understand which actions to perform. By default, the action assumes that this file is called reviewpad.yml and lives in the root of the repository.

The pull request workflows are specified in YAML. The major advantage with respect to other GitHub Actions is that it comes with a domain specific language (DSL) to quickly access contextual information in the pull request and perform actions.

Consider the following configuration:

workflows:
  - name: label-pull-request-with-size
    if:
      - rule: '$size() < 50'
        extra-actions:
          - '$addLabel("small")'
      - rule: '$size() >= 50 && $size() < 150'
        extra-actions:
          - '$addLabel("medium")'
      - rule: '$size() >= 150'
        extra-actions:
          - '$addLabel("large")'

It specifies a Reviewpad workflow to automatically add a label to the pull request based on the size of changes (measured in the number of lines added and deleted).

We currently have over 65 built-ins that allow you to manage labels, comments, reviews and merge pull requests.

Reviewpad’s trunk-based development

Based on TBD practices, we use Reviewpad to auto-merge pull requests in our main open-source repository reviewpad/reviewpad.

For us, the first step was to define which scenarios it makes sense to auto-merge pull requests.

Since the repository is public, we need to restrict auto-merges to pull requests authored by owners of the project.

Additionally, to enable this auto-merge feature, the pull requests should be directly flagged by the owners as Ship pull requests. The only requirement was that this flag mechanism should be automatic when opening the pull request.

Finally, we established two criteria for auto-merges Ship pull requests opened by owners:

Changes to Markdown files should be automatically merged; additionally, such pull requests shouldn't waste resources such as running the CI process;
Other changes should be automatically merged if the CI process is successful.

Regardless of the author of the changes, we also wanted to avoid running the CI process unnecessarily. So, pull requests that only modify Markdown files should not trigger the CI process.

The implementation

In this section, we show how we get Reviewpad to automate the merges.

The first step was to find a flexible mechanism for developers to open a pull request and flag them as Ship. We heavily rely on the GitHub CLI to open pull requests and we open them as fast as possible.

So we decided to use pull request templates to allow developers to select which approval/merge mode they want. This is part of our organization pull request template:

## Description

... for the entire file, please follow the link above :)

## Code review and merge strategy (ship/show/ask) 

- [ ] Ship: this pull request can be automatically merged and does not require code review
- [ ] Show: this pull request can be auto-merged and code review should be done post merge
- [ ] Ask: this pull request requires a code review before merge

In the final section of the template, authors of pull request select this mode.

As soon as the pull request is opened, the developer shouldn't have to do anything else.

We achieved this with two GitHub Actions:

reviewpad.yml that runs Reviewpad;
pull_request_build.yml that runs the CI with a job called pr-build.

As soon as a pull request is created, the Reviewpad action will be triggered and reads the configuration file.

We now highlight the relevant sections of the specification.

Check for ship pull requests authored by owners

The first step is to specify a rule that will be true if the pull request has been selected as Ship and is authored by an owner.

We start by defining, with the Reviewpad DSL, the group owners as the list of GitHub usernames marcelosousa and ferreiratiago.

groups:
  - name: owners
    spec: '["marcelosousa", "ferreiratiago"]'

Then, we define a rule that checks if the pull request contains in the description the section of the Ship mode. For this we can use the Reviewpad built-ins $contains and $description.

rules:
  ...
  - name: ship-mode
    spec: '$contains($description(), "[x] Ship:")'

We can use this rule to define the rule ship-authored-by-owners that checks if the pull request is both authored by an owner and was flagged with Ship.

rules:
  ...
  - name: ship-authored-by-owners
    spec: '$rule("ship-mode") && $isElementOf($author(), $group("owners"))'

Check for pull requests that only modify Markdown files

The first auto-merge criteria is to auto-merge pull requests that only modify Markdown files.

To do this, we define a rule changes-are-in-markdown that checks if the files modified only contain .md extensions.

rules:
  ...
  - name: changes-are-in-markdown
    spec: '$hasFileExtensions([".md"])'

Finally, we define the rule ship-markdown-changes that chains the previous rules and if true, should trigger the merge action.

rules:
  ...
  - name: ship-markdown-changes
    spec: '$rule("ship-authored-by-owners") && $rule("changes-are-in-markdown")'

Check for pull requests that have successful CI

The other criteria for the auto-merge involves the following steps:

Trigger the CI action if the changes are sensitive;
Check if the CI action was successful.

For the first step, we conservatively trigger the CI process if the changes involve other file extensions. We define it by simply negating the result of the rule changes-are-in-markdown.

rules:
  ...
  - name: changes-should-be-built
    spec: '!$rule("changes-are-in-markdown")'

We then combine this rule to define a Reviewpad workflow that adds a special label run-build.

workflows:
  - name: add-label-for-build
    if:
      - rule: changes-should-be-built
    then:
      - '$addLabel("run-build")'

The event of adding this label triggers the CI run in pull_request_build.yml with a job called pr-build.

We leverage the fact that you can trigger GitHub Actions based on other GitHub Action workflows. This allows us to trigger Reviewpad once the build finishes.

Reviewpad comes out of the box with built-in functions that allow us to check the result of workflow jobs. So, we defined a rule ci-is-green that checks if the pr-build job succeded.

rules:
  ...
  - name: ci-is-green
    spec: '$workflowStatus("pr-build") == "success"'

Finally, we can combine the rules to define the second auto-merge criteria:

rules:
  ...
  - name: auto-merge-authored-by-owners-with-ship-and-green-ci
    spec: '$rule("ship-authored-by-owners") && $rule("ci-is-green")'

Auto-merge pull requests

Once we have the rules that define the auto-merge criteria of interest, we just need to use them in a workflow that will trigger the $merge built-in. This built-in receives the merge method - we decided to use rebase to preserve the commits in the pull request.

workflows:
  ...
  - name: auto-merge-owner-pull-requests
    if:
      - rule: auto-merge-authored-by-owners-with-ship-and-green-ci
      - rule: ship-markdown-changes
    then:
      - '$merge("rebase")'

See it in action

When an owner opens a Ship pull request, if the changes are only in Markdown files, the pull request will be automatically merged without wasting the resources to run the CI.

See the following pull request for an example.

If the changes are in other file extensions, Reviewpad will add the run-build label and this label will trigger the CI. Once the CI job is completed, the Reviewpad action will run again and now validate the result of the CI.

This way we can automatically merge pull requests with the guarantee that the CI process was successful.

See the pull request for an example.

That's it! This is how we ensure that some pull requests are systematically merged without manual code reviews with the guarantee that the CI process is green.

If you are curious to see the whole process in action, check out our GitHub repository.

PS. Please give us feedback on Discord and support our project on GitHub with a star!

Ship / Show / Ask With Reviewpad

Marcelo Sousa — Fri, 08 Oct 2021 14:36:42 +0000

Ship / Show / Ask is a methodology to get faster releases with pull requests. With Reviewpad you get a code review platform that allows teams to naturally apply this methodology and extend it to new scenarios that give you greater velocity and team communication by going beyond pull requests.

Pull requests have been widely adopted by software teams as a way to collaborate in codebases. For all their benefits when contributing to open source projects, when it comes to projects where individual contributors have the power to merge their changes, pull requests slow software development.

Pull Requests Are Slowing You Down

The first reason pull requests are slowing you down is that theyare being used to document developer work.

If you need to open a pull request for every change, regardless of whether it is a new feature or a cosmetic change in a file, inevitably pull requests will be a bottleneck to integrate changes into a product.

When you associate “pull request” to “unit of dev work” and combine it with automated CI/CD pipelines, you get an overhead of time + resources that doesn’t always make sense in a fast-paced environment.

The second reason why pull requests are slowing you down is that we have associated code reviews with pull requests to a degree that we now use them interchangeably.

The truth is that not all pull requests need code reviews.

By enforcing processes such as “every pull request must be approved by a team member”, which is not aware of the actual changes, we have created a wait time in the process that is unreasonable in many situations.

This coupling of code reviews with pull requests has another major pitfall.

Because reviewing code is hard and the tooling around code reviews in pull requests is quite limited, it is standard to constraint the number of changes in a pull request. This means that changes that should be pushed together have to be broken up to accommodate this process.

Ship / Show / Ask

Ship / Show / Ask is a methodology to get faster releases by categorising changes into Ship (merge without pull request), Show (merge with pull request + later review) and Ask (standard pull request with review approval).

This methodology is powerful but still relies on the existence of pull requests. This limits you to always having to discuss changes between branches and trigger some automated process even when you just want to ask. It can also happen that you might need to do a later review but the changes were wrongly classified as Ship.

We think there’s a better way.

Code Reviews without Pull Requests

Reviewpad decouples code reviews from pull requests so that you fully embrace the idea that not all pull requests need code reviews and that code reviews can be done without pull requests.

Let’s take a look!

Reviewpad – Creating a Review Between Commits

With Reviewpad it is possible to practice the Ship / Show / Ask methodology in a more flexible way. In fact, what we have been practicing at Reviewpad is a Ship / Show / Ask / Revise methodology.

Ship

If you want to push a change to the main branch and you have the confidence to do so, you should just do it.

You shouldn’t have to wait for the CI checks or a review approval on a pull request to do so. Anyway, you typically run some CI pipeline in the main branch so you can always backtrack if something goes terribly wrong. You should have the power and trust to simply push changes.

Show

A Show process is when you run the CI checks over a branch before the merge, merge and only later get a review.

Although you can do this with a pull request, with Reviewpad there is really no need to do so. You can simply wait for the CI pipeline to finish when you push to a feature branch, merge, and then open a code review between those commits in the main branch. You can choose to open this code review to get later feedback between the branches or in the main branch itself.

Ask

The Ask process happens when you want feedback on our ongoing work.

Here we pause. We make our changes on a branch, we open a Pull Request, and we wait for feedback before merging. Maybe we’re not sure we’ve taken the right approach.

Unfortunately, for many developers, the idea of a pull request is more of a “work done” than a “work in progress”. In fact, mixing the two can be quite confusing because sometimes you just want early feedback on code that you know will not pass the CI checks.

Reviewpad allows you to create a code review between commits to get that feedback, revise it, close this code review and then open a pull request kicking off the official merge process in a team. That encourages more collaboration and communication about the code.

You can use the same code review interface regardless if you what you are reviewing is a pull request or just a diff between two commits.

Revise

So what happens if you want to revise some code that went into the main branch? This could be useful in the case of a huge load of pull requests with no time to review them or because you wrongly considered changes to be in “Ship” mode.

By going beyond the limitation of reviewing code with pull requests you can revise code in a single branch.

This allows you to create code reviews that document specific parts of the code, or to keep track of changes when you spend some time away from the project.

If you find issues in this mode, you can always connect to the code host by creating issues from comments.

Reviewpad – Creating an issue from a comment

Conclusion

With Reviewpad, you get a tool that provides the flexibility of new methodologies such as Ship / Show / Ask and beyond so that you can get the full benefits of code reviews and continuous integration without the limitations of pull requests.

You can try now at beta.reviewpad.com.

Mitigating Conflicts In Pull Requests

Marcelo Sousa — Wed, 01 Sep 2021 16:13:13 +0000

One of the most annoying tasks for a developer is to fix git conflicts. You open a pull request, ace the code review process, all checks are passing, and when you go for that merge button you find out that it is blocked because of git conflicts. Wouldn’t it be nice if you could avoid this situation?

Developers that use a git flow branching model rely on 3-way merge tools (like git-merge or kdiff3) to automatically merge their changes.

Unfortunately, these tools are unable to resolve all concurrent changes made to files in the branches involved in the merge. As developers, we experience these unresolved concurrent changes as git merge conflicts. As the name suggests, the existence of a git merge conflict prevents the merge action.

The exact definition of a git merge conflict depends on the algorithm used to compute the merge commit. The most widely used algorithms are textual in nature – a conflict in a file means that the branches involved in the merge have both made modifications to the same line in a file. Nowadays, there are much more sophisticated algorithms to compute merge commits than what is offered in GitHub, Gitlab, or Bitbucket. For an overview check out the article Verified Three-Way Program Merge – we do plan to incorporate some of them soon into Reviewpad.

However, a merge is and always will be a sensitive operation. That is, some concurrent changes really do conflict and require human intervention.

The reality is that git merge conflicts are relatively common in highly collaborative teams.

There are currently 27 pull requests blocked in the google/guava project because of git conflicts.

While some conflicts are unavoidable, it is possible to create awareness of their future existence so that you can mitigate their effects.

Reviewpad’s Concurrent Pull Request Analysis

At Reviewpad, we believe that git conflicts are being discovered at a very late stage in the review process. That is very annoying because sometimes after you have gone through the entire review process you find out that a recently merged PR just introduced git conflicts. Now, you need to restart the entire process.

So, to reduce this effort we have built into Reviewpad a concurrent pull request analysis that provides information about future git conflicts.

Information about conflicting changes with ongoing reviews at google / guava – #5654 Remove redundant bit masking.

The way Reviewpad keeps track of potential future git conflicts is by checking if modified files in a particular pull request are also modified in other open pull requests that share the base branch.

We have been using this check in two use cases that improve the review process.

Improve reviewer selection

Finding the right reviewer can be difficult at times in highly collaborative projects. Who better to review than a developer who is also changing the same parts of the code, or a reviewer of such PR?

Example of pull request without reviewers that has conflicts with concurrent PRs.

In the video, we can see that there is another open PR that is also changing the ci.yml. The author of that pull request could be a great candidate to review this pull request. Ideally, both developers could collaborate so that all conflicts could be avoided once one of the PRs is merged.

Improve merge strategy

As we mentioned in the beginning of this article, there is nothing more annoying than a pull request that is ready to merge but will be blocked by the merge of another PR. Although we can’t completely avoid this situation, we have integrated this check into Reviewpad’s Release Board so that it becomes evident.

In this first version, we have decided to restrict this information to pull requests that are ready to merge. Here’s what a PR card with conflicts in concurrent PRs looks like:

Pull request card that is ready to merge and that has conflicts with another PR that is also ready to merge.

In the following video, we go over the simple flow of approving a PR, seeing the conflicts in the Ready to Merge column and also the effect of merging this PR which moves the conflicting PR back to the Git conflicts column.

Integration of concurrent PR check with Review Board in the Ready to Merge column.

Cool. How do I check this out by myself?

We have a public beta version of Reviewpad available at reviewpad.com/get-started. You will need to create a new account and once you log in for the first time, you will see the following page to connect to a code host:

Connect to code host page on Reviewpad.

You can connect to GitHub through our OAuth app or manually add a personal access token. The OAuth requires minimal scopes to be able to read and comment on public repositories.

And voilà – you are ready to get started with Reviewpad!

We are just getting started with incorporating features that improve the merge experience in pull requests. Feel free to reach us on our community Slack with requests!

When You Merge Pull Requests You Lose Knowledge

Marcelo Sousa — Tue, 24 Aug 2021 15:33:30 +0000

What happens to comments and discussions of a pull request when it is merged? Isn’t that knowledge valuable for the team? Why isn’t it readily accessible to future pull requests?

Pull requests (PRs) are a mainstream way of proposing changes to a codebase. One of the most important features around pull requests is the ability to perform a code review, allowing developers to inspect and comment on the proposed changes.

Frequently, the knowledge in these comments is invaluable to the team. Reviewers, which are familiar with the codebase and related technologies, will notice bad patterns, suggest optimisations, enforce team guidelines and best practices, etc.

However, as soon as you merge that pull request on GitHub, Gitlab, or Bitbucket, all this information is lost into the bag of closed PRs that you will rarely (if ever) inspect.

We all have had that déjà vu feeling when writing a comment in a code review: “Didn’t I write this comment already?” When preparing a PR sometimes we also have that feeling: “I think I’m forgetting something in this line of code.” Or better yet: “Didn’t someone already thought of this before?”

Let’s look at three scenarios.

1. Knowledge useful to a broader audience

Knowledge that could be beneficial to developers not involved in this codebase. For instance, this comment could be useful for other developers modifying similar code.

Discussion by kgabryje at apache / superset “feat(native-filters): add search all filter options #14710“

2. Knowledge about design decisions

Teams with a lot of contributors can suffer from problems associated with the lack of context in design decisions. For instance, when a decision was taken on a discussion on a previous pull request. Consider the following discussion:

Discussion with halspang and artursouza at dapr / dapr “Write reminders in multiple partitions #3297“

Assuming that this PR is merged, when someone else modifies this code in the future, it would be useful to retrieve this discussion. In this case, that would be particularly relevant if this person starts the support for a decrementing path.

3. Review déjà vu

Senior developers that are active reviewers also experience what we call review déjà vus. These are situations where you are repeating similar comments in different PRs, like this one:

Comment by timotheecour at nim-lang / Nim “oids: switch from PRNG to random module #16203“

These situations also occur when there are some hidden assumptions that do not make sense to document in the code.

Wouldn’t it be nice if we could re-use the comments from past reviews into future PRs without having to maintain them?

Enter Reviewpad

Reviewpad builds semantic diffs of changes in pull requests and associates metadata such as comments to these semantic objects. This is a big shift from the current behavior of existing code hosts such as Github, Gitlab, and Bitbucket. They associate comments to a line of a file in a particular git diff – as soon as the contents of the line change, this comment is marked as outdated.

We’ll showcase Reviewpad with the Web Crawler exercise of A Tour of Go using the linked GitHub repository. In this exercise of A Tour of Go, we are given a first implementation of a fake web crawler – the exercise is to parallelise it and prevent fetching the same URL twice.

Semantic git diffs

As a first step, we used Reviewpad to create a pull request with this first implementation.

Reviewpad interface for pull request after review and merge

Reviewpad performs a relational static analysis (in the style of [1] and [2]) over the git diff associated with the pull request to build semantic diffs. These semantic diffs form what we call the Explore Tree in Reviewpad.

Explore tree for pull request

An explore tree is an annotated file tree of the modified files. For each modified file, we present an annotated semantic tree of the changes. For example, the file fakeFetcher.go as presented on GitHub requires an entire scan to understand the main symbols added: 1) the type fakeFetcher, 2) the struct fakeResult with two fields body and urls and 3) the method Fetch. Note that the method Fetch is shown as a child of the type fakeFetcher as it is the receiver type. At the moment, our analysers focus on types and methods – this is why we don’t show variable fetcher. The color in the beginning of the symbol indicates the type of modification: green for added, red for deleted and yellow for modified.

We show the explore tree on the left of the description and general conversation so that developers can quickly match the description and discussions to code changes.

Each element of the explore tree is clickable to its representation in the git diff. For example, clicking on the fakeFetcher type directs the user to the beginning of the symbol in the diff:

Navigation from the explore tree to the code diff

Note: For those you noticed the coloured icon next to the file go.mod – this means that the file is automatically hidden from the review mode. Each Reviewpad user can tweak their file view in their review settings to exclude files.

In this PR, I did a first review to document parts of the code. For example, while the original code for Crawl is:

// Crawl uses fetcher to recursively crawl
// pages starting with url, to a maximum of depth.
func Crawl(url string, depth int, fetcher Fetcher) {
    // TODO: Fetch URLs in parallel.
    // TODO: Don't fetch the same URL twice.
    // This implementation doesn't do either:
...
}

I chose to comment on the function as a code diff comment. These review comments are inserted into the knowledge base maintained by Reviewpad:

Diff comment in Crawl function

Note that the comment in the explore tree appears as a child of Crawl symbol. This means that the comment was made in the definition of the symbol (not just in its signature).

Comments from past reviews

After the PR with the initial code was squash and merged, I created a new PR with a solution presented by the GitHub user harryhare.

Reviewpad interface for pull request with first solution

The explore tree again shows the overview of the solution which involve the introduction of a SafeCounter struct with a map v to check if an URL was visited, a mutex mux and a method checkvisited that checks if URL was already visited or not.

The rest of the solution involves changes to the functions Crawl and main to fetch URLs in parallel. In the Crawl method, Reviewpad presents the comment from the past PR that documents the method. This way, developers can retrieve discussions from previous PRs that changed this method.

Code diff view with comment from previous pull request

A user review raised an issue with the checkvisited which is fixed in the commit [fix from review](https://github.com/reviewpad/dejavus/pull/3/commits/a629a38fddad2305a13f2ce07da6a001c263920b).

A final review approves the PR with the request to remove the TODOs in the code.

In the final commit of this PR, we add the reference to the solution as a code comment in the Crawl method and remove the TODOs.

Reviewpad interface for all changes in pull request

Hovering on the function Crawl in the explore tree displays the code documentation associated with this function for readability.

Keeping track of comments and changes over time

At this point you might be wondering:

What happens if the comment was made in a PR that was not the exact previous one?
What happens if I start refactoring the code?

To answer these questions, let’s go over the two open PRs in our project.

The first is an improvement proposed by another Github user that uses wait groups.

Pull request proposing an improvement using wait groups

The comment shown in this pull request was the one made in the first PR. Reviewpad tracks comments regardless of their time difference. For example in the following PR from the google/error-prone project:

Reviewpad review mode for pull request of the google/error-prone project. You can check it on Github here.

The PR was opened in September 2020 and it is changing class methods that were commented in January 2020.

The second open pull request demonstrates a beta version of our refactoring analyser:

Pull request with a refactoring

In this PR, we introduced two commits, the first that changes the signature of the function Crawl by renaming the variable url to reqUrl and the second renames the file.

Reviewpad understands that it is the same function and presents the comment made in the first PR. Note that we are squash and merging these pull requests – the commit associated with the comment is not an ancestor of the commits in this PR.

Cool. How do I check this out by myself?

We have a public beta version of Reviewpad available at https://reviewpad.com/get-started/. You will need to create a new account and once you log in for the first time, you will see the following page to connect to a code host:

Connect to code host page on Reviewpad

You can connect to GitHub through our OAuth app or manually add a personal access token. The OAuth requires minimal scopes to be able to read and comment on public repositories.

And that’s it – you will be able to give Reviewpad a spin on public repositories! We will be adding more and more public repositories in the upcoming days – feel free to reach us on our community Slack with requests!

References

[1]: Cartesian hoare logic for verifying k-safety properties.

[2]: Verified three-way program merg e.

Visualising Changes With Semantic Git Differences

Marcelo Sousa — Fri, 30 Jul 2021 16:52:12 +0000

Yay – you receive a notification for a code review in a pull request on GitHub. You open the files changed tab on GitHub and there it is: a basic UI showing you nothing more than a git diff. Surely, there is a better way to look at the changes, including comments, and navigate to them, right?

git diff is a great tool used by millions of developers every day. One of the ways developers consume it is through the UI of GitHub, GitLab, or Bitbucket when you doing a code review.

Unfortunately, what you see is literally what you get out of the git command.

For example, here is what you see on GitHub.com for the following pull request of the google/guava project:

Files changes in google/guava – #3304 Unhandled overflow in the concat() method of per-type primitive utility classes

We believe that in 2021, developers deserve better than having to exhaustively check textual diffs and try to reverse engineer the context of the changes.

So we have incorporated into Reviewpad a special diff operation that captures an overview of the changes at the semantic level:

Reviewpad’s Explore Tree. Try our beta at beta.reviewpad.com.

The Explore Tree was designed to immediately answer the following questions:

From the list of modified files, which have changes that involve semantic changes and how many changes occurred?
Which semantic objects (e.g. methods and classes in Java) were modified and which type of modification (added, removed, or changed)?
Which files or symbols contain comments?

Answering these questions has saved us a lot of review time as the tree also acts as an index into the diff, and allows us to navigate directly into it.

Interactions with the Explore Tree for Google / Guava – #3304 Unhandled overflow in the concat() method of per-type primitive utility classes. Check it out on beta.reviewpad.com/review/github.com/google/guava/pull/3304.

In order to compute the Explore Tree, Reviewpad performs a semantic diff of two versions of the file, restricted only to the hunks associated with the git diff. From there, the challenge is to understand which symbol (function, method, class, type, etc) is associated with this change. We’ll write more details about the analyser in a future post. 😉

Cool. How do I check this out by myself?

We have a public beta version of Reviewpad available at beta.reviewpad.com. You will need to create a new account and once you log in for the first time, you will see the following page to connect to a code host:

Connect to code host page on Reviewpad.

You can connect to GitHub through our OAuth app or manually add a personal access token. The OAuth requires minimal scopes to be able to read and comment on public repositories.

And voilà – you are ready to get started with Reviewpad!

Our semantic analysis works for more than 10 languages including: C, C++, C#, Go, Haskell, Java, Javascript, Proto, Python, Ruby, Rust, Swift and TypeScript.

We are adding more and more open source projects in different languages so that you can check it out easily. Feel free to reach us on our community Slack with requests!

A Board To Rule All Pull Requests

Marcelo Sousa — Tue, 20 Jul 2021 11:24:25 +0000

Pull requests are king. Still, even royalty needs to be monitored to optimise certain processes. Project management tools do a good job keeping track of issues and their associated pull request but they are not close enough to the action. We propose a new way of monitoring pull requests to minimise their time to merge.

Pull requests are a widespread tool that developers use to propose changes to git repositories. Yesterday alone (July 15th, 2021), there were almost 120 000 pull requests opened over public repositories on GitHub.com. With all this activity, it can become hard to understand which open pull requests require attention and what is the appropriate action.

Pull requests in large repositories

Whenever a team is managing a large repository, it can become difficult to navigate the sea of open pull requests. The google/guava project, which contains Google core libraries for Java, is an example of such a large repository. Here’s what the open pull request list looks like:

The standard view of open pull requests in Github.com. In this case, google/guava pull requests.

Currently, GitHub provides a list of pull requests with filtering capabilities such as labels, review information, and relevant participants. However, with this view, for a particular pull request, it is not clear what is the main blocker and who could unblock it.

Pull requests in projects across multiple repositories

The second scenario is when a project is distributed over multiple git repositories. If you want to get a sense of what is happening in the pull requests on the entire project, you need to open each individual project pull request listing. As an example, for the Apache APISIX project, which involves 7 git repositories, you would need to open 7 different views individually.

Overview of all the pull requests in a project with more than one repository.
In this case, Apache APISIX.

Not only is this annoying, but it also misses potential dependencies between pull requests from different repositories. Suppose that you have a project composed of two microservices distributed in two different git repositories where one is a library and another is a consumer of this library. It is not uncommon for, within the same release, to have a change that requires changes in both repositories where pull requests are related to each other.

A board to rule all pull requests

To help teams structure their reviews and release processes, we have added to Reviewpad a fully automated board of pull requests that is fully integrated with GitHub, GitLab, and Bitbucket. The board represents the lifecycle of pull requests across all projects known to Reviewpad. It allows teams to easily understand and resolve bottlenecks when it comes to pull requests. By the way, by design, it requires zero configuration and it is not configurable for now. We wanted to have a board that emulates the simplest review process that could be used by teams that are starting to do code reviews, and teams that are going back to basics!

Reviewpad’s **Pull Requests Board**, as seen on Reviewpad Beta at https://beta.reviewpad.com/board

The ultimate goal of this board is to facilitate communication during short meetings, to decrease the overall time to merge. At Reviewpad, we have been using this board for our daily syncs as opposed to a board of issues with the mindset of continuous code reviews, and it has substantially reduced friction in our releases.

In this current form, the release board has a pre-determined and fixed set of seven columns, and it should be interpreted as a pipeline. For example, a pull request in the column of Missing approvals is guaranteed to have git conflicts. Similarly, a pull request that has Failing protection rules is guaranteed to already have the required approvals for merge.

Here’s the information on each card:

Card for PR google/guava #3372 Improve efficiency of bulk removals in transformed lists.

The information is composed of four sections:

General information – project, title, author, last updated time and branches involved in the pull request;
CI checks results;
Reviewers state;
Labels.

So far, we have found that with this information we can quickly understand the issue blocking the pull request and the person who can help unblock it.

Filter by repository, participant or label

Simplicity is key. The only filters you can apply to the board are to select repositories, participants, or labels. Here’s an example of filtering by the google/guava project.

Filtering pull requests

The board becomes particularly useful when you have a project that is distributed in multiple git repositories like the example we showed above.

Filtering pull requests of a project with more than one repository. In this case, Apache APISIX.

One trick that is particularly powerful with our board is to re-use labels between git repositories, for example for milestones or priorities.

Fully automated

A basic requirement we wanted for our board is that it must be fully automated. For instance, if a pull request is in the column for missing approvals gets the required approvals, the card that represents this pull request should automatically advance in the pipeline.

Automation in action.

The automation is not tied to the usage of Reviewpad. In the example above, the card would automatically move forward, to the Ready to merge column, if the approval was done directly on GitHub.

Cool. How do I check this out by myself?

We have a public beta version of Reviewpad available at https://beta.reviewpad.com. You will need to create a new account and once you log in for the first time, you will see the following page to connect to a code host:

Connect to code host page on Reviewpad

You can connect to GitHub through our OAuth app or manually add a personal access token. The OAuth requires minimal scopes to be able to read and comment on public repositories.

And that’s it – you will be able to give Reviewpad and the release board a spin on public repositories! We will be adding more and more public repositories in the upcoming days – feel free to reach us on our community Slack with requests!

Continuous Code Reviews Are The Way To Go

Marcelo Sousa — Tue, 15 Jun 2021 17:54:55 +0000

One of the major roadblocks for quality code reviews is how their complexity can quickly get overwhelming. The three major factors of this increasing complexity are well-known: the number of changes; the maturity of the codebase; the expertise of the reviewer. Of course, you also have time constraints that amplify this complexity.

If we don’t figure out techniques and workarounds for these issues, we are hindering the full benefits of code reviews.

We have made it our mission to tackle this complexity.

It is all about the process

In a recent Harvard Business Review article, David De Cremer and Garry Kasparov write about Augmented Intelligence and how the synergy between artificial intelligence and human intelligence can lead us to new levels of productivity.

Weak human + machine + better process was superior to a strong computer alone and, more remarkably, superior to a strong human + machine + inferior process.

Garry Kasparov

The key aspect for success is the process by which humans and machines collaborate. This is our philosophy for Reviewpad. So what’s this process for us?

Continuous code reviews are the way to go

We are stating this outright. We are very much continuous code review evangelists.

We believe it is the practice that best allows us to avoid the single greatest hurdle in code reviews, which is its mounting complexity. In this article, we will explain why. We will also explain what we mean, because:

Continuous can mean different things

Context switching incurs a lot of overhead. (…) In a continuous code review you don’t have this problem. Your pair is right there giving you feedback as you go. From little things like variable naming to bigger things like noticing a bug or telling you about an existing class you should use. The code is updated in real time.

Allan Stuart on Continuous Code Reviews

His solution implies two developers working on the same code at the same time. One of them actually creating original code, and the other reviewing live.

This is possibly as close to actually continuous as you can possibly get, but it’s not the only way to achieve this effect.

Not every company can assign two developers to the same job at any given time. Also, not every company has a pair like Jeff Dean and Sanjay Ghemawat. And the truth is, we are still understanding how pair or mob programming is adapting to remote environments.

Reviewpad is being designed to provide the same sort of collaborative and continuous mindset without this multiplication of effort.

The analyses it provides address the aspects where people are more error-prone. It’s a tool that augments human intelligence.

We believe in breaking things up into tiny parts. We also know that you don’t need pull requests to achieve that.

Our process: code review centric development

It is a well-known practice in software development to separate work into sprints and do daily syncs. In these daily syncs, you have a squad, which typically includes developers, designers, and a product owner. Someone puts up a board of issues from Jira (or some other project management tool) and the entire team goes over it.

This is a problem.

Miscommunication between the description of a Jira task and the description of a pull request happens all the time.

We propose an inversion of control. After a written high-level specification is shared with a developer, it is up to them to specify the intent of a particular changeset for development. The product owner must then understand what fraction of the high-level task these changes amount to, and adjust if necessary.

Why is this preferable? It significantly reduces specification overhead by product owners who do not have (or don’t have the time to acquire) a good understanding of the codebase. It also reduces artificial pressure on development by reducing the guesswork regarding the completion of a task.

Reviewing ideas will save you ages

Think of it as architecture. You’re building a castle. When do you bring in someone to check your work? When the castle’s already built may be a tad too late.

The idea that code reviews should only be about fixing mistakes is misguided. Code reviews should be about creating better, more efficient, code. If an idea is misguided, or flawed, then it hardly matters whether the code brings it to life perfectly.

Reviewers should be a part of the process from the get-go.

Code reviews are the central piece of this approach and that’s why we call it code review centric development.

How does it work?

As soon as a developer plans to change something in the codebase, the first step is to open a code review stating the intent of the changes and assigning reviewers. This signals to the rest of the team what this person is working on and how we can help them achieve success continuously.

Some of the benefits we have experienced in the past months are:

reduced miscommunication, because we are asking early technical and non-technical questions about the approach;
faster development, because we are regularly checking changes to see the progress;
more shared knowledge, because of more frequent and better feedback;
fewer integration problems, becausewe detect potential future conflicts.

Reviewpad was built to facilitate this type of development. Instead of forcing developers to look at a kanban of issues (which relate to the product owner, but not them), we use a dashboard of code reviews to easily communicate real progress and potential pain points.

The length of the review is as long as the developer wants it to be, since feedback is given on a continuous basis.

Instead of forcing developers to switch between contexts a dozen times to complete a code review, you can do reviews that are quicker, more focused, and kinder to your brain.

Draft Pull/Merge Requests are an excellent starting point

The adoption of code review-centric development is going to take time. This is why Reviewpad seamlessly integrates with GitHub and GitLab.

An excellent starting point to this approach is to use WIP or draft pull requests.

This feature allows you to create a draft of your pull request before you make any changes at all. And you can immediately assign a reviewer. Ideally, more than one.

If you do this diligently (and we recommend making at least two checkpoints in your draft PR a day), any reviewer who is available will be able to come in whenever they’re notified of changes, and provide you with more feedback. This way, you and your team can start feeling the benefits of continuous, iterative code reviews.

Reviewpad’s integration of the code host draft pull/merge requests, alongside its sophisticated communications arsenal means that it’s possible and easy to start the review process earlier. In the brilliant idea stage.

We recommend that developers draft every pull request they do as soon as they think it up. Before they even touch the code. Again: If you clearly signal your code changes before they are even made, a reviewer will not only know what they’re looking for, they’ll be able to comment on your intention as well.

Async, yet continuous

If you take this iterative approach and take full advantage of the draft PRs, your reviewer doesn’t need to be working the code at the same time as you. They will be notified as soon as you have your idea, and they will be able to provide feedback on it much earlier.

Still, you need to help them! They will only be able to understand changes that much quicker if your intent is laid out clearly. If they know what they’re looking at, they will have an easier time spotting mistakes, or code that quite simply doesn’t do what it’s supposed to.

This back and forth between a developer and a reviewer is the perfect way to go about it. It’s async, yet continuous. We’re working on the right set of features to make this process easy and enjoyable.

If reviews are done this way, then they will effectively keep up with development. Over time, your codebase will never build up unreviewed, regardless of how mature it is. Conversations between developers and product owners will feel more natural and transparent. In the long-term, your team will have the right mechanisms to re-enforce trust and ownership – and when that happens, you have coding superpowers.

If you are interested in Reviewpad or hearing more about code review centric development talk with us!

Context Switching: Why It Hurts Code Reviews And What We Are Doing About It

Marcelo Sousa — Fri, 11 Jun 2021 13:44:40 +0000

Context switching, not fear, is the mind-killer. One of the main obstacles to quality code reviews is the simple fact that developers have a lot to do. The cost of going back and forth during code reviews and between code reviews and other tasks is standing between us and excellence.

But we can help.

We are letting context switching get in our way

In several ways, actually. There are several types of context switching, and they are all harmful in their own specific manner.

One of Reviewpad’s main goals is to reduce the amount of context switching you are doing today.

So, what exactly do we mean by context switching?

Our brains don’t excel at multitasking

A bold claim, right? But it’s true. Cognitive load theory is a useful framework to understand how our brain processes information. There’s a lot of science about this.

The basic idea is that we store knowledge in the long-term memory of our brains, yet we are only consciously aware of a chunk of this memory. The so-called working memory. In other words, our brains (much in the same way as a computer that has limited RAM) can only store and manipulate a certain amount of information at any given time. If you exceed that amount, you generate errors, stereotyping, or both.

No two brains are the same. However, according to Miller’s law, an average human can only concurrently store and manipulate seven different elements in their working memory. This is what we call cognitive load.

Whether the magic number is 7, 9 or 4, several studies have suggested that humans are particularly poor at complex reasoning using totally new information in working memory. Still, this memory is fundamental to form knowledge that will be stored in long-term memory.

According to cognitive load theory, working memory load can be affected by three kinds of cognitive load.

Intrinsic cognitive load: How difficult the subject matter actually is. (2+2 is easier to understand than E=mc²).
Extraneous cognitive load: How much the format is helping or hindering you. (It’s easier to read in your native language than your second language).
Germane cognitive load: How efficient you are at structuring your thoughts. (A trained mathematician will learn new math faster than an equally skilled linguist).

What happens when you’re reading a novel and you stop to reply to a tweet? Even if you were paying the utmost attention to what you were reading, you will replace whatever elements were in your working memory. When you get back, you will have to reread a couple of words, maybe a couple of sentences, to find your place. It may take you a couple of minutes to refocus on what you were doing.

This is pretty much how we’re doing code reviews at all times.

Context switching hurts all developers

We have context-dependent memories. We have, as we mentioned above, limited cognitive loads. Modern work environments aren’t ideal for total focus. Especially in the kind of fast-paced environments that most developers find themselves in. Context switching is constant. Email, Slack, IDE, Jira, Teams, Zoom, meetings, clients. Every time you go from one environment to another, your brain needs to gather context so it can refocus. The effects of this are known, and they’re not ideal.

Code reviews, in particular, are heavily affected by this.

We need to prioritize code reviews in our work

Code reviews often are context switches. If a developer is squeezing code reviews into a busy schedule, then the code review itself will constitute a switch in context.

So why would we prioritize code reviews?

Shouldn’t we let code review requests accumulate and then handle them all at once?

Absolutely not.

As I have discussed in my previous post, the complexity of reviews increases exponentially with the number of changes, the maturity of the codebase and the expertise of the reviewer. For a team to move forward with a project with a lot of unreviewed code is a costly thing to do. It will lead to mistakes and bugs that will be costlier to fix with every passing day.

It goes without saying that for any elements of your team to be stuck waiting for code reviews isn’t ideal either. Even if they do have other tasks they can get to in the meantime, that’s just extra context switches.

There are solutions for this. Greg Sanford, from Slack, advocates for checking (and resolving) your code review requests whenever you interrupt work. Allan Stewart, of Pluralsight, advocates for continuous code reviews, with developers working in pairs. We’ll write about how we cope with it in a future post.

Teams need to find strategies to reduce the amount of context switching between development and code reviews.

But that’s not the only kind of context switching.

Context switching between tools during review is hell

And that’s where we come in.

When developers are doing code reviews, they are using an excessive number of tools.

Slack, or another messaging app, will be there, to get a notification and reach the original author of the code.

Then you move to a review interface to understand the differences and provide feedback. This typically will be the Web UI of GitHub, GitLab, Bitbucket or some other code host.

After that, there will be some juggling with a project management tool, such as Jira, to understand the scope of the changes, and with the IDE to understand some parts of the code.

This is a veritable Babel tower of context switching. Reviewers will be switching between a series of environments to help understand the code and its scope.And then, they will switch between tools to communicate the review. A typical code review requires the developer to switch context endless times and none of these tools was actually designed from the ground-up for the review process. What ends up happening is that you spend a big chunk of your review time context switching. After a while, your brain will be screaming “LGTM”.

This is detrimental not only to the review itself but to all the other tasks being carried out alongside them. Can you imagine what happens to your short-term memory with that much extraneous cognitive load? It’s not a coincidence that you get a coffee before and after doing a complex review.

Here’s how we’re fixing it

I acknowledge that context switching between tasks isn’t something Reviewpad can fix. That’s a question of team culture that companies have to tackle (we hope they will!). But we can help with both the tools used to understand the code and those used to communicate.

Code reviewers shouldn’t be switching between these many tools. At Reviewpad, we believe that your browser can replace most of the suite of apps we described above.

We are integrating the entire review cycle into one tool.

First of all, you shouldn’t need an IDE anymore. IDEs are for coding –that’s a different cognitive task than understanding code or suggesting edits in a review. Reviewpad will provide you with the semantic context that you need to understand the code changes and identify functional bugs and security vulnerabilities. You will also be able to review changes easily by iteration (push or commit) to break down complex reviews into manageable chunks. We’re designing Reviewpad while aware of the limits in cognitive load so that you don’t feel overwhelmed with information.

How about communication?

Reviewpad provides new ways of giving and receiving feedback during reviews. It achieves this without comments being lost (because you modified a line of code) or having to go into a meeting to understand the overall structure of the changes. Everything is integrated with current code hosts so that you can have a smooth transition process.

If this looks good to you, you should book a demo with us. We would love to show you how much time Reviewpad can save you and your team.

If you are facing problems with code reviews, please share them with us – we’re here to help.

The need for simpler code reviews

Marcelo Sousa — Mon, 24 May 2021 09:03:52 +0000

Code reviews are one of the best ways to ensure code quality.

A recent survey has found that 36% of the companies that do code reviews think it is the best way to improve code quality. Too often, however, they are understood as an individual task, instead of a team effort.

Here are five reasons that motivate the need for simpler code reviews.

We aren’t teaching enough how to do code reviews. People are entering the market much faster than they are being promoted. Code reviews, by and large, are not taught at University.
Code reviews are not being prioritised. When the code is being developed without an effective integration of the reviewing processes, it often gets done last minute.
Code reviews are not an individual task. Most teams assign this responsibility of code reviews to either team leads or senior developers alone. This is unsustainable when there are the ration of junior to senior developers is increasing.
Code reviews need to withstand staffing changes. Leads and senior developers leave. Sometimes they’re absent. If they are the ones doing code reviews, in these events we observe huge bottlenecks in code reviews.
We need the right tools. A large number of teams are still doing manual code reviews or using tools that are time consuming and error prone.

If you want to read more, check out the full article on Reviewpad's blog.

Six best practices to improve your code reviews

Marcelo Sousa — Thu, 13 May 2021 19:37:02 +0000

Code reviews are complex. They involve good time management, high emotional intelligence, knowledge of the codebase, and technical expertise. It is a team process where practice and communication are everything.

Here are six best practices to improve your code reviews:

Review Your Pull Requests Before Others
Encourage Reviewers To Be Co-Owners
Leverage Automation
Always Have A Reviewer In Mind
Time Your Code Reviews
Create A Top 10 List Of Pull Requests To Learn From

If you want to read more, check out the full blog post.

DEV Community: Marcelo Sousa

Automate pull requests with GitHub Starter Workflows

The Problem

The Solution

The Setup

Step 1. Specify the pull request automations in Reviewpad

Step 2. Add the Reviewpad starter workflow to the .github repository

The Demo

Modern Trunk-Based Development

What changed?

A different perspective

The best of both worlds

Reviewpad’s trunk-based development

The implementation

Check for ship pull requests authored by owners

Check for pull requests that only modify Markdown files

Check for pull requests that have successful CI

Auto-merge pull requests

See it in action

Ship / Show / Ask With Reviewpad

Pull Requests Are Slowing You Down

Ship / Show / Ask

Code Reviews without Pull Requests

Ship

Show

Ask

Revise

Conclusion

Mitigating Conflicts In Pull Requests

Reviewpad’s Concurrent Pull Request Analysis

Improve reviewer selection

Improve merge strategy

Cool. How do I check this out by myself?

When You Merge Pull Requests You Lose Knowledge

1. Knowledge useful to a broader audience

2. Knowledge about design decisions

3. Review déjà vu

Enter Reviewpad

Semantic git diffs

Comments from past reviews

Keeping track of comments and changes over time

Cool. How do I check this out by myself?

References

Visualising Changes With Semantic Git Differences

Cool. How do I check this out by myself?

A Board To Rule All Pull Requests

Pull requests in large repositories

Pull requests in projects across multiple repositories

A board to rule all pull requests

Filter by repository, participant or label

Fully automated

Cool. How do I check this out by myself?

Continuous Code Reviews Are The Way To Go

It is all about the process

Continuous code reviews are the way to go

Continuous can mean different things

Our process: code review centric development

Reviewing ideas will save you ages

How does it work?

Draft Pull/Merge Requests are an excellent starting point

Async, yet continuous

Context Switching: Why It Hurts Code Reviews And What We Are Doing About It

We are letting context switching get in our way

Our brains don’t excel at multitasking

Context switching hurts all developers

We need to prioritize code reviews in our work

Context switching between tools during review is hell

Here’s how we’re fixing it

The need for simpler code reviews

Six best practices to improve your code reviews

Step 2. Add the Reviewpad starter workflow to the `.github` repository