DEV Community: LinearB

gitStream vs Code Owners vs GitHub Actions

LinearB — Sun, 16 Apr 2023 22:35:27 +0000

Code review is an essential part of all your software development projects. But sometimes, your org follows an inefficient PR process, applying the same sets of policies to every pull or merge request, regardless of the change. This can increase the lead time from making a change to releasing it to production. Your teams’ cycle times will also take a massive blow and your devs will be frustrated.

But new methods are constantly emerging to make the PR lifecycle smoother 😉. These often mix automation and human interaction to reduce the time to merge. In this article, you’ll learn about some of the newer tools that help automate your workflow including GitHub Actions, code owners, and LinearB’s very own gitStream.

What Is GitHub Actions?

GitHub Actions is a CI/CD platform that allows you to create pipelines to automate build processes. Actions are like methods you’ll use when programming and performing tasks in the repo. GitHub Actions can support the merge process, but they’re a lot of work to set up on your own. If you can’t find a pre-existing Action to perform the activity you want, you need to create it from scratch or find an open-source example.

While this tool’s automation aspect can equate to better efficiency, Actions by default work at the repository level and don’t provide a lot of granular control without a lot of highly specific work in YAML. This means it can take quite a lot of time to set up and maintain. The automation process could also allow low-quality code to be automatically merged without merge request approval. GitHub Actions is limited to GitHub and not as versatile as Code Owners — you’ll find out why next.

What Is Code Owners?

Code owners is a feature in version control systems like Git that allows users to assign ownership to specific files or directories. It ensures the assigned owners review changes before merging them into the codebase. You can also use code owners to automate workflows, such as triggering notifications to owners when changes are made. It’s commonly used in open-source projects to manage contributions from external contributors.

The code owners feature was first introduced by GitHub in 2017. While GitHub did not invent the concept of code owners, it popularized it by integrating it into its platform and making it more widely accessible to developers. Since then, the adoption of code owners has been quite widespread, particularly among developers who use Git-based version control systems like GitHub, GitLab, and Bitbucket. These platforms all support code owners in some form, allowing users to assign code ownership and automate workflows.

GitHub Code Owners

Within GitHub, code owners enables you to configure a repo’s code owners with a file named CODEOWNERS. This helps you ensure the right people are reviewing the code they have the most interest in.

You can configure the repository only to allow code to be merged after approval by a default owner. You can even break it down further, so that specific files require code owner approval, while anyone can approve others.

Using the GitHub CODEOWNERS file reduces the risk of changes being merged without approval from code owners, which helps with overall code quality. But this can reduce efficiency, especially if these specific devs need to review many changes.

For example, when Symphony Talent used code owners, they eventually got into a situation where eight senior developers all had to review all the PRs. Each of them received dozens of PRs a day, and there was no way to manage it all without ownership. Without knowing who should review what, this created a bottleneck. With gitStream, they can now assign the reviewer based on the PR author team, and each team has a senior reviewer.

GitLab Code Owners

Similar to GitHub, with GitLab code owners, you can define who develops and maintains a feature and owns the resulting files or directories in a repository. Using a CODEOWNERS file, you can ensure merge requests are approved by code owners before merge or even protect a specific branch by only allowing code owners to approve changes to the branch.

You can also use GitLab Code Owners and approvers (with approval rules) to build a more flexible workflow. This requires you to:

Use code owners to define the users who have domain expertise for specific paths in your repository
Use approvers and approval rules to define domains of expertise (such as a security team) that aren’t scoped to specific file paths in your repository

Check out this video on Code Owners in GitLab for more information:

Example of a CODEOWNERS File

Create a new file called CODEOWNERS in the root, in the branch where you'd like to add the code owners.

# This is a comment.
# Each line is a file pattern followed by one or more owners.


# These owners will be the default owners for everything in
# the repo. Unless a later match takes precedence
# @global-owner1 and @global-owner2 will be requested for
# review when someone opens a pull request.

*       @global-owner1 @global-owner2


# Order is important; the last matching pattern takes the most
# precedence. When someone opens a pull request that only
# modifies JS files, only @js-owner and not the global
# owner(s) will be requested for a review.

*.js    @js-owner #This is an inline comment.


# In this example, @doctocat owns any files in the build/logs
# directory at the root of the repository and any of its
# subdirectories.

/build/logs/ @doctocat


# The `docs/*` pattern will match files like
# `docs/getting-started.md` but not further nested files like
# `docs/build-app/troubleshooting.md`.

docs/*  docs@example.com


# In this example, @octocat owns any file in an apps directory
# anywhere in your repository.

apps/ @octocat

What Is gitStream?

gitStream is a dynamic rule engine that allows you to define PR conditions and results. You can implement the same behavior of code owners with it. The difference is that you can add more conditions, not just based on file path patterns, and you can use dynamic data.

For example, you can assign a reviewer based on who wrote the PR and other conditions, like file path. You can also assign a reviewer based on dynamic analysis of the code source control history, e.g., “rankByGitBlame” and more.

For example, eMed uses gitStream on a repo that contains binary assets and JSON files to support their procedure scripts. Some of these procedures are live in production, but many are strictly internal test data or in-development assets unavailable to customers.

They wanted a system where live production assets and procedures would be properly reviewed by various people (clinical, legal, UX and design, etc.), but the in-dev and testing resources could be deployed freely.

They even wanted to auto-approve production procedures if the changes were strictly in formatting, without any substantial content. They were never quite able to achieve this complexity using code owners, but with gitStream it’s working beautifully! 🙂

Want to learn how to implement custom dev workflow automation to cut code review time by up to 40%? Watch this hands-on workshop to set up the free gitStream tool to automatically:

✅ Classify and route pull requests
✅ Add estimated review time to PRs
✅ Apply custom rules

gitStream product lead, Ofer Afias, will take you through a live demo of the three core functions when getting started with gitStream workflow automation to scale your team efficiently and improve your developer experience.

gitStream vs Code Owners vs Git Actions

When choosing a workflow automation tool for your team, the four most important factors to consider are the tool’s 1) scalability, 2) risk, 3) efficiency, and 4) customization. These factors impact the tool's ability to handle increasing workloads, minimize potential issues, optimize performance, and accommodate unique development requirements.

Without these four factors aligned, your teams can’t succeed. So, we’ve analyzed each tool against these key factors to help you out!

1. Scalability

Using Git code owners is the least scalable approach, as devs still need to perform manual code reviews before merging code. If the same person has to review a lot of pull requests, the process can become a huge bottleneck while the code owner struggles to catch up.

gitStream and GitHub Actions are significantly more scalable. They both automate the merge process and can prevent unnecessary manual reviews for trivial changes. gitStream can even automate the reviewer selection process based on several criteria that require no editing when new team members are added!

2. Risk

GitHub Actions are scalable, but risky, because they allow even poor-quality code changes to be merged. In contrast, Git code owners doesn’t allow code to go through without merge request approval from specific people, so it’s low risk. But this comes at the cost of being tough to scale.

When it comes to risk, gitStream outperforms the other two methods. It provides a more sophisticated rule set to determine which changes can automatically be approved, which ones require approval from code owners, and which ones need multiple reviewers.

3. Efficiency

Using Git code owners isn’t a great option if you’re looking for efficiency. Code owners can get bogged down with time-consuming reviews on active code bases. GitHub Actions are efficient and have automation capabilities, but their high-risk nature means your teams will have to deal with an increasing number of bugs, reducing their overall efficiency.

A GitHub Action is also a low-level operation that requires effort to code, test, and maintain. gitStream, on the other hand, is a more high-level system that allows you to apply many automation rules very easily. Again, gitStream offers significant advantages over the other methods. It ensures your teams don’t waste time on low-level reviews, while also eliminating the risks of bugs.

4. Customization

All three options provide a level of customization, like defining who the code owners are and specifying what changes can be automatically merged. But code owners only allows you to choose who the reviewer is and which files are important. And while you can customize GitHub Actions to some extent, they’re limited to a specific scope.

gitStream provides the most options, effectively offering the functionalities of both GitHub Actions and code owners — and then some. gitStream is built on top of GitHub Actions and shares some similarities with them. But gitStream gives you much more power and granularity down to the file level that matches a regex rather than affecting the whole repository. gitStream is also free and can be implemented much faster and more dynamically than GitHub Actions.

Bonus Round

gitStream can achieve the same capabilities as using GitHub Code Owners, while also enabling you to incorporate additional conditions to better align with your teams’ evolving requirements.

The tool also offers a wider range of use cases. For example, it enables you to automate more complex Git workflows like automatically labeling pull requests, triggering notifications to external tools or systems, and routing pull requests based on multiple criteria. This allows your teams to optimize their Git workflows to better align with their specific development processes and requirements.

To help you make your decision faster, check out the table below for a quick recap on how each tool ranks:

When to Use Each Tool

Each workflow automation tool has its strengths and weaknesses, but they can all serve a purpose within a specific context. To help you out, we’ve highlighted three scenarios in which you can opt for either of the three tools, depending on the size and scope of your teams’ projects.

1. Low-Complexity Projects with GitHub Actions

GitHub Actions are great for fast-moving, low-complexity projects. Because GitHub Actions allow for rapid merge, the increased speed will probably outweigh the risk. GitHub Actions can help you speed up projects when quality isn’t your primary focus. So it works well when you have a small team working on a fairly straightforward project.

That said, GitHub Actions aren’t ideal for larger projects with more critical, complex elements. While GitHub Actions can help you move through your project faster, they’re not ideal when errors are out of the question. The initial speed boost this tool provides will surely result in code-breaking bugs that can halt your progress.

2. Code Owners for Smaller Codebases

Code owners provide a low-risk, low-speed approach to code merge. This makes code owners a useful approach for smaller projects without tight deadlines. The CODEOWNERS file is also good for projects without highly regulated and audited applications, where even the smallest mistake can spell catastrophic consequences.

Code owners also isn’t suited for larger codebases with frequent changes, as the code owners can quickly become overwhelmed with reviews. Code owners can help ensure the quality of your teams’ code, but this comes at a price — speed.

3. Streamline Multi-Codebase Enterprise Applications with gitStream

gitStream is optimized for projects of any size with any number of developers. It provides an optimal mix of automated merge and human code reviews depending on the context of the change. This makes gitStream applicable to most real-world use cases, especially if you have a large engineering team with several repositories, each with different owners and specialists.

gitStream ensures code gets merged quickly, while also upholding quality so you can reduce your cycle time safely. As a bonus, gitStream helps you eliminate the biggest bottleneck development teams often face: slow PR cycles. So gitStream doesn’t just speed up your processes while maintaining quality, it also boosts devs’ morale and reduces their frustration.

Improve your engineering efficiency with gitStream! It's free on the GitHub marketplace. Learn more.

Make Your Move on Merge

Standardizing your PR review process with policy-as-code is important because the time it takes to merge can cause delays in bug fixes, feature releases, and your teams’ overall cycle time. It’s also critical to avoid causing devs anxiety because they can’t do any work with all the constant context switching.

If you’re looking to increase your merge frequency, GitHub Actions and code owners can be good options. But you need to be mindful of your projects’ size and risk appetite to avoid sacrificing quality for speed and vice versa.

On the other hand, gitStream helps your teams create dynamic code owner rules so you can continuously merge while maintaining high code quality. This tool marks a shift from the one-size-fits-all procedure for all pull requests that slows down your time to merge and negatively impacts cycle time.

gitStream also allows your teams to move beyond these rigid requirements, sizing the depth of review needed and assigning the reviewers based on who’s best suited. Because gitStream can seamlessly handle projects of different sizes and is free, it’s a great option for most real-world business projects.

Thank You CODEOWNERS, It's Time for Code Experts

LinearB — Sun, 09 Apr 2023 20:24:11 +0000

This article was written by Natalie Breuer for LinearB.

Engineering teams no longer have to choose between Git blame or Git activity when it comes to assigning the best PR reviewer — they can now have both.

Enhance your current CODEOWNERS workflows with new dynamic pull request routing and classification by gitStream, a PR automation tool built around ensuring that your code is getting the highest quality review possible.

Year after year, research from DORA has maintained that by reducing manual work in the code review process, engineering teams can decrease change failure rate up to 40% and reap the benefits of higher ROI on engineering. It was with this data in mind that GitHub launched CODEOWNERS in 2017, thereby ushering in a new era of agile centered around workflow automation.

And while the widespread adoption of CODEOWNERS has been a great first step toward continuous merge, it has remained a one-dimensional solution. While CODEOWNERS does allow users to assign developers or teams to specific files, it does not take into account more dynamic data, like history, activity, developer expertise, or team workload.

Ensure the Highest Quality Review for Every PR

For engineering organizations looking to boost efficiency, the pull request review process is the best place to start. If you’re interested in enhancing your current CODEOWNERS workflow, here are new rules that will make your pull request reviews more effective:

Code Experts: Authorize experts only for sensitive code
High-Risk Tags: Let DevSecOps take the reins on high-risk work
Missing Tests: Mark PRs without tests
2 Reviewers: Require 2 reviewers for complex PRs

Authorize Experts Only For Sensitive Code

When it comes to high-risk code, it’s imperative that changes are thoroughly reviewed by the most qualified person before they are deployed.

As such, one of the most popular gitStream rules is the ability to assign codeExperts to a review.

gitStream’s proprietary algorithm takes into account which developers have the most commit activity and knowledge on the files in question, then assigns them to review that PR automatically.

Let DevSecOps Take The Reins on High-Risk Work

Many dev teams love CODEOWNERS because it allows them to flag risky code by file or directory. With gitStream, users can also alert users based on code changes relevant to their team.

This is especially useful for reviews in sensitive areas of the codebase. For example, DevSecOps can flag risky code terms to ensure that PRs containing those terms are reviewed by their team.

In the example above, a gitStream user has defined a required field: description. Doing so will route all PRs with this component to DevSecOps every time.

Mark PRs without Tests

gitStream can also flag high-risk PRs in the pipeline, so engineers can spend their time on what matters most and catch bugs before they happen.

Whenever a PR without a test is opened, gitStream applies a bright red label.

Then, once the tests are added and committed, gitStream will automatically remove the label.

Require Two Reviewers for Complex PRs

Historically, when engineering teams have wanted two approvals on a complex PR, they’ve had to increase the required reviewer count for all PRs using GitHub repo settings.

This lack of flexibility within GitHub has forced engineering managers to choose between two evils: either assigning developers to more PRs than necessary or forgoing a second set of eyes on sensitive reviews.

gitStream solves for this dilemma by allowing users to assign two reviewers for PRs they deem complicated or high-risk.

In the example above, the user has added a rule that requires two developers to approve PRs with more than 100 lines of code changed under the src directory.

Help Your Dev Team Ship Code 44% Faster

With all that said, code quality is only one side of the equation. Top-performing engineering organizations must also optimize for speed to remain competitive in a down economy.

And it’s a common misconception that engineering teams must sacrifice code quality at the expense of pace. Rather, DORA research has “consistently shown that speed and stability are outcomes that enable one another.”

To this end, gitStream can also help decrease cycle time up to 44% by enabling developers with:

Auto-Approvals: Approve safe changes automatically
Reverse CODEOWNERS: Share knowledge across teams
Deprecated API Alert: Request changes on deprecated APIs

Approve Safe Changes Automatically

Most PRs with simple revisions to documentation don’t need to take up your engineers’ precious time. Now, users can leverage gitStream to verify and auto-approve all documentation changes.

In the example above, the files context is checked by an allDocs filter that verifies the PR only contains document files.

Share Knowledge Across Teams

As important as it is to keep your developers unblocked day-to-day, it’s also critical to ensure that your team is improving month-over-month.

One of the easiest ways to do this is to let gitStream assign engineers to PRs based on their lack of knowledge. This can be a great way to familiarize devs with new areas of the codebase and facilitate knowledge sharing across your team.

As seen in the rule below, by setting lt to 50, only those who contributed less than 50% of lines overall will be assigned to the PR.

Request Changes on Deprecated APIs

Another popular gitStream rule is the ability to trigger a change request automatically whenever a PR includes use of a deprecated API. This allows engineering managers to encourage best coding practices on their team while remaining hands off.

This way, whenever a developer accidentally opens a PR using an old API, they will get the following automated alert redirecting them toward the preferred API.

Transition from Static CODEOWNERS to a Dynamic Review Policy

As with the launch of CODEOWNERS in 2017, gitStream marks a shift in the way developers will automate their workflows for years to come. Gone are the days of a one-size-fits-all approach to code reviews.

And unlike CODEOWNERS, which involves manual upkeep as teams and priorities shift, gitStream was built for scale, with highly customizable rules and little to no maintenance.

Setting up gitStream takes less than 3 minutes. Watch our installation tutorial below and set up your first rule today.

You Don't Need to Sacrifice Developer Experience for Productivity

LinearB — Sun, 02 Apr 2023 22:24:21 +0000

I recently came across a story in the book Atomic Habits that got me thinking about how small changes end up making significant impacts. About 25 years ago, Dave Brailsford set out to revamp Great Britain’s cycling team which had been mediocre for a century. His strategy became known as “the aggregation of marginal gains.”

Brailsford explained it like this: "The whole principle came from the idea that if you broke down everything you could think of that goes into riding a bike, and then improved it by 1%, you will get a significant increase when you put them all together."

This approach proved tremendously successful. At the 2004 Olympics, Team GB won two gold medals. In 2008 and then again in 2012, they won eight.

The strategy of the aggregation of marginal gains applies to software engineering too. Rarely is a developer’s workflow suboptimal because of just one or two big factors. Rather, there’s a lot of little things that in aggregate result in a bad developer experience.

What better way to create high-performing, highly-engaged engineering teams than to help your engineers optimize their workflows and improve developer experience?

Focusing on Velocity Is an Anti-Pattern

Being an engineering lead means you're under constant pressure to ship more features. But you face the constant constraint of too few resources. That’s why pretty much everyone is trying to hire more developers, but it can take a long time to find the right people.

So how do you ship more features without expanding the team?

The obvious solution seems like it would be to boost velocity. This is the approach many leaders want to take when they first become a team lead. As our COO Dan explained in a previous post, thankfully, an experienced dev on the team warned him that this was a bad idea.

Find out why agile velocity is the most dangerous metric for software developers. Look at 12 alternative metrics instead.

Perhaps the easiest way to boost your development velocity is to ask your team to do more. This can work, for a while. But eventually your team is going to get burnt out. Some may even take a job at another company. Ultimately, your velocity is going to drop and you may be left in an even worse position than you started in.

This was exactly what happened to Ben Matthews, Director of Engineering at Stack Overflow. At a previous company, he focused too narrowly on increasing developer velocity. He told the cautionary tale at Interact, our annual conference for engineering leaders:

Boost Productivity By Improving Developer Experience

If you can’t expand the team (at least not immediately) and you can’t increase your team members’ WIP, what are you supposed to do?

The answer lies in recognizing that increasing the number of features your team ships and developer well-being are not mutually exclusive. Quite the opposite, in fact! By improving developer experience in the right ways, you can boost your team’s productivity.

If we hire engineers to write code, and they want to write code, then why do they constantly struggle to carve out time to do it?

There are 3 kinds of issues that eat up a developer’s time and prevent them from focusing on building new features.

1. Time Spent Not Coding

Outside of coding, developers spend most of their time in meetings (although there are certainly plenty of developers who spend more time in meetings than coding!)

One of the worst kinds of meetings is when each person simply updates everyone else on the status of their work. Daily scrums can easily devolve into this. In turn, either your daily scrums have to run longer or members of the development team have to make do with less time to surface their blockers and get help from their teammates.

We’ve tried to do away with a lot of status update meetings and check-ins. If you want to know, “Who is working on project XYZ?” or “Where is my team spending their time?,” you don’t need to ask your team members. This only takes up their time and interrupts their focus. Instead, you can just check in LinearB’s Pulse view.

Check out this awesome dashboard we use for our standup. It identifies who's blocked, who has too much WIP, and if our work is aligned with the business priorities. Learn more about Pulse!

Developers are also forced to spend a lot of time managing the “metadata” around the code they write in project management tools like Jira. We studied over 1,000 dev teams and found that on 71% of teams, over 30% of all WIP branches were unlinked to an issue in Jira.

Shadow work like this means that you can analyze project status and team performance all day, but because the underlying data isn’t accurate, your insights can’t be trusted.

With our WorkerB bot, your devs don’t need to go into Jira to create a ticket for shadow work. WorkerB will alert them if they have an unlinked branch and then allow them to create a ticket, in just one click, from right within Slack. Teams who have started using the One Click Ticket feature have seen a 67% drop in unlinked branches.

Switching between tools also prevents developers from focusing, an issue we’ll look at next.

2. Context Switching

“Flow state” has become a big buzzword lately - and with good reason. When you’re in “flow,” you’re doing your best work and you’re having the best time. Studies show an extremely strong correlation between time spent in flow and overall happiness.

Unfortunately, it’s becoming increasingly difficult for engineers to access a flow state. When they’re not jumping in and out of meetings, they’re jumping from their IDE to Slack to Jira to Gmail.

We built our WorkerB automation bot to solve this problem. From right within Slack you can:

See the estimated review time of PRs
Review and approve small PRs (less than 5 lines of code or diffs)
Check on the status of your PRs and the PRs assigned to you to review

When developers know in advance how long a review will take, they can slot them into those moments where there are natural context switches, like between meetings or when transitioning from one larger task to another. Or they can estimate how much time they need to block off in order to work through a backlog of reviews all at once.

By enabling developers to stay informed about PRs and to review small ones from within Slack, WorkerB is saving them a bunch of context switches into GitHub or Gitlab.

3. Idle Time

At Interact, Luca Rossi, founder of Refactoring.club, spoke about the importance of reducing pull request pickup time.

He said, “We spend incredible effort to, for example, shave 10 minutes off our CI/CD pipeline and then we have code sitting with nothing to do for 20 hours and later on someone says, ‘I’m waiting for someone to read it.’”

Luca had a lot of great thoughts about code reviews, which you can listen to below:

At LinearB, we discovered that the biggest wait time in development cycles is at the code review stage. Luca gave the example of 20 hours, but the reality is even worse. Based on our analysis of over 733,000 branches from almost 2,000 engineering teams, we found that on average, PR reviews take over 4 days!

A main reason that reviews take so long is that PRs spend a lot of time simply waiting to be reviewed. Our analysis found that:

50% of pull requests were idle for 50.4% of their lifespan
33% were idle for 77.8% of their lifespan

Reducing PR pickup time is an easy yet extremely effective way to increase the efficiency of your team. It doesn’t get higher leverage than this!

The single best way to reduce PR pickup time is to reduce PR size. Large PRs take a long time to review. And because they take a long time to review, developers have to wait to review them until they have a big block of time (which is hard to come by for the reasons we looked at above).

Our analysis shows short PRs (<220 lines of code) can be reviewed more quickly. A lot more quickly–I’m talking 10x more quickly!

Our Team Goals helps you establish and then track your progress against goals like reducing PR size or keeping the PR lifecycle under 4 days (ideally under one day based on our Engineering Metrics Benchmarks study.)

WorkerB is integrated with Team Goals so that it can inform team members when, say, they’ve created a PR that exceeds the goal set by the team. With WorkerB, you can even approve PRs shorter than 5 lines right from Slack.

WorkerB combined with Team Goals creates an engine for sustained improvement on dev teams.

Parting Words

Just as Dave Brailsford relied upon the aggregation of marginal gains strategy to turn Team GB into an elite cycling team, you can use it to boost your team’s performance.

By leveraging LinearB’s WorkerB bot, you make slight reductions in time not spent coding, time wasted by context switching, and idle time. The combined effect of these reductions will improve your developers’ happiness and make your team more productive. Everyone wins: you, the developers, users, and the company as a whole.

This is why one of LinearB’s core principles is to optimize developer workflow. Our WorkerB bot helps automates the annoying, tedious parts of the job and enables developers to stay in flow, doing what they do best: solving problems and building features.

To learn about all the ways LinearB empowers you to build high-performing engineering teams, get in touch to set up a demo.

Want to improve your engineering processes at every level? Get started with a LinearB free-forever account today!

How to Add Estimated Review Time and Context Labels to Pull Requests

LinearB — Sun, 19 Mar 2023 21:09:48 +0000

The pull request (PR) review process, if not set up well in your team, can create a lot of bottlenecks in getting your code merged into the main branch and into production. By adding more context and information automatically to your PRs, you save yourself and your team work.

Take the scenario of fixing a typo in documentation. If there’s a backlog of PRs that need attention, such a PR may take two days — or longer — just to be approved. This is where continuous merge (CM) with gitStream comes in.

gitStream is a tool that allows you to add context and automation to your PRs, classifying PRs based on their complexity.

This ensures that a review won't stay in the queue for long as it can be quickly assigned to the right person, immediately approved or have the appropriate action identified easily.

This hands-on article demonstrates how to add gitStream CM to your repository.

In this article, you’ll learn:

How to Configure your Repository
How to Create Pull Requests (PRs)
How to Add the CM Feature to Your PRs

Quick gitStream Setup Guide

If you’re keen to get all the benefits of gitStream and continuous merge right away, all you need to do is follow these simple steps. If you want to understand how gitStream works, how you can customize it and more options, it will follow right after.

Choose Install for free on gitStream's GitHub marketplace page
Add 2 files to your repo:

a) .cm/gitstream.cm
b) .github/workflows/gitstream.yml

Open a pull request
Set gitStream as a required check

A Comprehensive Guide to gitStream & Continuous Merge

Filter functions and context variables are used to effect automated actions, such as adding labels (add-label@v1), assigning reviewers (add-reviewers@v1), and approving requests (approve@v1), among others.

Everything is included in a .cm configuration file named gitstream.cm.

All instructions to gitStream CM are detailed in the docs found at docs.gitstream.cm. gitStream also uses GitHub Actions to do its work, so you’ll need to add the gitstream.yml file to your GitHub Actions directory at .github/workflows/.

The main components to fulfill gitStream’s CM are:

The configuration files: gitstream.cm and gitstream.yml.
The filter functions: Code that tries to check and/or select certain data types from the input for checks during a PR creation.
The context variables: The inputs fed to the filter functions.
The automation actions.

Note: Some steps use Python only for demonstration purposes. It’s not required knowledge.

Prerequisites

To follow this tutorial, ensure you have the following:

Hands-on knowledge of Git and GitHub workings. You must know activities such as creating a repository, PRs, commits, and pushes.
A GitHub account.
Git installed in your working environment.

You can find and review the final project code here.

Step 1 - Set Up gitStream on Your Repo

Create an empty repo and give it a name, then install gitStream to it from the marketplace.

After installation, you can either: 1) Clone the repository to your environment; or 2) Create a folder and point it to the repository. This tutorial uses the second option.

Create a folder called gitStreamDemo. In this folder, create two directories, .github/workflows and .cm, using the commands in a terminal window below:

mkdir -p .github/workflows

mkdir .cm

In the .github/workflows folder, create a file called gitstream.yml and add the following YAML script:

name: gitStream workflow automation

on:

workflow_dispatch:

  inputs:

    client_payload:

      description: The Client payload

      required: true

    full_repository:

      description: the repository name include the owner in `owner/repo_name` format

      required: true

    head_ref:

      description: the head sha

      required: true

    base_ref:

      description: the base ref 

      required: true

    installation_id:

      description: the installation id

      required: false

    resolver_url:

      description: the resolver url to pass results to

      required: true

    resolver_token:

      description: Optional resolver token for resolver service

      required: false

      default: ''

jobs:

  gitStream:

    timeout-minutes: 5

    # uncomment this condition, if you dont want any automation on dependabot PRs

    # if: github.actor != 'dependabot[bot]'

    runs-on: ubuntu-latest

    name: gitStream workflow automation

    steps:

      - name: Evaluate Rules

        uses: linear-b/gitstream-github-action@v1

        id: rules-engine

        with:

          full_repository: ${{ github.event.inputs.full_repository }}

          head_ref: ${{ github.event.inputs.head_ref }}

          base_ref: ${{ github.event.inputs.base_ref }}

          client_payload: ${{ github.event.inputs.client_payload }}

          installation_id: ${{ github.event.inputs.installation_id }}

          resolver_url: ${{ github.event.inputs.resolver_url }}

          resolver_token: ${{ github.event.inputs.resolver_token }}

Next, create a file called gitstream.cm in the .cm folder and add the following code:

manifest:

  version: 1.0

automations:

  show_estimated_time_to_review:

    if:

      - true

    run:

      - action : add-label@v1

      args:

       label: "{{ calc.etr }} min review"

       color: {{ '00ff00' if (calc.etr >= 20) else ('7B3F00' if (calc.etr >= 5) else '0044ff') }}

  safe_changes:

    if:

      - {{ is.doc_formatting or is.doc_update }}

    run:

      - action: add-label@v1

       args:

       label: 'documentation changes: PR approved'

       color: {{'71797e'}}

      - action: approve@v1

  domain_review:

    if:

      - {{ is.domain_change }}

    run:

      - action: add-reviewers@v1

      args:

       reviewers: [<listofreviewers>]

      - action: add-label@v1

      args:

       label: 'domain reviewer assigned'

       color: {{'71797e'}}

  set_default_comment:

    if:

      - true

    run:

      - action: add-comment@v1

      args:

       comment: "Hello there. Thank you for creating a pull request with us. A reviewer will soon get in touch."

calc:

  etr: {{ branch | estimatedReviewTime }}

is:

  domain_change: {{ files | match(regex=r/domain\//) | some }}

  doc_formatting: {{ source.diff.files | isFormattingChange }}

  doc_update: {{ files | allDocs }}

In the file, you’ll see the following four automation actions:

show_estimated_time_to_review: This automation calculates the estimated time a review to a PR may take.
safe_changes: This shows if changes to non-critical components done in a PR are safe, such as document changes. The PR is automatically approved.
domain_review: This automation runs to show if a change was made to the domain layer.
set_default_comment: This is fired every time a PR is opened and raises an acknowledgment comment to the user that a PR has been created.

At the end of the document, there’s a section containing filter functions for the automation actions. The actions are run after certain conditions specified in the filter functions or keys are met.

Step 2 - Calculating the Time to Review

In the first automation, check the value of the etr variable and decide which label to assign to the PR. For more information on how ETR is calculated, check out this blog.

Create a file called main.py in the root of your folder. Then, create three folders using the command below:

mkdir views domain data

Add the following to the main.py file:

def show_message(name1, name2):

  print(f'Hello, {name}. Welcome to the gitStream world')

if __name__ == '__main__':

  print_hi('Mike')

Copy the main.py file as is and paste it to the other three folders. Rename them to match the folders’ names (domain.py) for the domain folder.

For the dummy documentation file, create a README.md file in the root of your folder and add the following markdown script.

# gitStreamDemo

A demo showing how to set up gitStream on your first repo

Now, run these commands to initialize the repository, stage the files for committing, and make a commit, in that order:

git init

git add .

git commit -am “initialization”

Next, point the folder to your repository using the command below:

git remote add origin https://github.com/<your-username>/<your-repo-name>

Finally, push it:

git push -u origin main

Step 3 - Creating the Repository

As you may have noticed, there’s a sample bug in the code. In any programming language, you must call the function using its exact name. But in this case, print_hi was called instead of show_message. As a team member or an open-source contributor, you can fix this by opening a PR.

First, create a branch called fix-function-call and checkout into the branch using the commands below:

git branch fix-function-call

git checkout fix-function-call

Next, replace the name print_hi with show_message in all the .py files, then commit and push the changes.

git commit -am “changed function name”

git push --set-upstream origin fix-function-call

Now, open your repository in GitHub. You’ll see the following card:

Click on Compare & pull request. On the next page, click the Create pull request button.

Once the gitStream automation has finished running, you’ll see the domain reviewer assigned tag. Additionally, a comment has been created.

Add this Dijkstra’s Shortest Path Algorithm script just below the show_message function in each of the .py files again. These scripts calculate the shortest path for a node in a graph.

Commit the changes and then push the code.

git commit -am “updates”

git push

Creating a Safe Change

For the final automation, you’ll add text to the README.md file created earlier. Create a new branch and checkout to it. You do so because you’ll need a new PR to demonstrate this automation.

git checkout main

git branch update_docs

git checkout update_docs

Then, add this sentence to the README.md file:

Continuous Merging is very beneficial to the Open-Source Community.

Commit and push.

git commit -am “updated the docs”

git push --set-upstream origin update_docs

When the checks are done, you’ll see a different label with the PR already approved.

Help Developers Make the Most of Their Time...

Reviewing and merging PRs are crucial in contributing to software development and enhancing team productivity. However, being unable to classify PRs by complexity can lead to long wait times or much back-and-forth in the review process.

CM remedies this issue by classifying PRs based on the complexity, automating some actions including tagging the appropriate reviewers, assigning them PRs, and approving PRs among others to reduce the backlog.

Check out gitStream to add CM to your existing repos.

The Workflow Metrics That Make Elite Dev Teams

LinearB — Sat, 11 Mar 2023 22:00:55 +0000

Since its inception in 2016, the DevOps Research and Assessment (DORA) program has provided dev teams with some great metrics to guide them on their journey to performing at an elite level. But DORA metrics should only be one piece of the puzzle.

Make no mistake, tracking DORA metrics are important and useful – just not for everything that an engineering team strives to do, such as showing how developers directly impact the business bottom line.

Used in tandem with LinearB’s Engineering Benchmarks, however, dev teams can start to use DORA metrics to power themselves toward elite workflows. Based on a study of nearly 2,000 dev teams and 847,000 code branches, these benchmarks help guide us toward what the 10% of dev teams that we consider elite look like in practice.

Want to learn more about being an elite engineering team? Check out this blog detailing our engineering benchmarks study and methodology.

Small but Powerful PRs are Best

What’s clear is that elite dev workflows start and end with small pull request (PR) sizes. In our experience, this is the best indicator of simpler merges, enhanced CI/CD, and faster cycle times.

PR size, rework rate, and deployment frequency all affect cycle times, but PR size continues to present the most significant opportunity for real organizational change.

Luckily, it’s also easiest to focus on reducing PR size. It’s concrete, measurable, and achievable. Elite teams make less than 225 code changes (including additions and removals), making them easier to review and safer to merge.

Because small PRs get picked up and reviewed fast, they lower cycle times and positively impact other DORA metrics. There are fewer hand-offs and less idle time. Production blow-ups are smaller and teams can recover more quickly.

Beyond efficiency and moving work through the development pipeline quickly, low PR pickup and review times also tell a good story about team chemistry. Teams that have a smooth code review process also tend to have better code quality.

To help streamline pull request merges, LinearB has released gitStream. This free dev tool allows teams to decide what pull requests should be deemed either low, medium, or high risk. The tool has already allowed hundreds of dev teams to deploy more frequently by systematically not treating all PRs the same.

Increasing Deployment Frequency

If PR size represents the guts of a project, deployment frequency is the heart. Teams should always strive to plan and work in small, manageable, and quickly releasable chunks. Good scoping and planning nets out to smaller PR sizes, resulting in a team that is constantly merging and deploying. The more frequent the deployment, the better the organizational cadence and developer experience.

The more frequent the deployment, the better the organizational cadence and developer experience.

It’s important to note that elite deployment frequency is daily – and anything more than a week suggests the need for critical focus. Daily deployment of code indicates a stable, healthy continuous delivery pipeline, which can happen quite naturally with lower PR sizes.

Smaller PR sizes correlate with higher test coverage and more thorough reviews (hallmarks of higher deployment frequency and code quality), reducing change failure rates (CFR). It’s also much easier to roll back and fix issues, helping to lower your mean time to restore (MTTR). Cycle times are lower, customers are happy, and so are developers.

Reworking and Refactoring

The concept of rework rate (or code churn) can sometimes be confusing. If a dev writes code, the code merges to the main “trunk,” or the release, and it’ll almost always be refactored in time.

People assume refactoring is bad, but refactoring 6- or 12-month-old code is a good thing.

It’s important to distinguish between rework and refactoring. Refactoring is a process of making preexisting code more efficient. Rework is the bad kind – a repeating pattern in a poorly functioning process. Or the rework could be due to a quality problem; perhaps product or engineering aren’t aligned on objectives?

Unless the code has just been committed, strong refactoring is a healthy sign of a well-functioning team. Teams with lower PR sizes, rework rates, and higher deployment frequency also have more time to focus on refactoring.

How Development Workflow Impacts Other Metrics

Understanding DORA metrics is important. They do matter, but they’re not enough.

PR size, deployment frequency, and rework rates all affect development workflow, impacting overall productivity and efficiency. Average, or even strong dev teams can grow stronger by zeroing in on these key metrics. When they do, other metrics like planning accuracy, CFR, and MTTR often fall in line.

A crucial dimension of LinearB’s Engineering Benchmarks study is that predictability stems from smaller PRs and shorter cycles. By looking at the key indicators, teams can foresee problems before they come up, and they have the time and space to plan for them. Instead of spending up to three cycles recovering, teams know exactly how long problem-solving will take – if those problems happen at all.

With proper focus and utilization, development workflow metrics can transform organizations. As useful as DORA metrics are, dev teams’ overarching goal should be using better indicators to power them into the elite-performing bracket with a supercharged development workflow.

Want to cut code-review time by up to 40%? Add estimated review time to pull requests automatically!

gitStream is the free dev tool from LinearB that eliminates the No. 1 bottleneck in your team’s workflow: pull requests and code reviews. After reviewing the work of 2,000 dev teams, LinearB’s engineers and data scientists found that pickup times and code review were lasting 4 to 5 days longer than they should be.

The good news is that they found these delays could be eliminated largely by adding estimated review time to pull requests!

Learn more about how gitStream is making coding better HERE.

This article was originally published on LeadDev.com on December 20, 2022.

What is Continuous Merge?

LinearB — Fri, 09 Dec 2022 23:01:39 +0000

Despite the workflow improvements that have been made with CI/CD, there are huge bottlenecks found in the pull request and code review process. These bottlenecks can be removed with continuous merge, a set of processes that make pull requests easier to pick up and code reviews quicker to merge.

Let's look deeper into what continuous merge is, why it's needed, and how to implement it with automation tools like gitStream.

The State of CI/CD

Plain and simple: Continuous integration/continuous delivery (CI/CD) has become standard practice for rapidly delivering new software features, bug fixes and enhancements.

Continuous integration (CI) is where developers merge individual code contributions into a central repository, where automated tests and builds are executed.

Continuous delivery (CD) automates code change deployment to testing and production environments. Continuous deployment — a term often confused with continuous delivery — is the final step of the DevOps pipeline, where all changes that successfully pass the production pipeline are released to customers.

CI/CD automates every step of the development process, ensuring products and features are shipped to users almost as fast as they’re developed. But it does have drawbacks.

Where CI/CD Can Be Improved

Many branches often extend from the central repository when multiple software developers work simultaneously on a large codebase.

Branches with long lifetimes (the period between review and merging) impede the performance improvement that agile practices like CI/CD seek to achieve.

Inefficiencies in the pull-request (PR) process create bottlenecks in the delivery pipeline, especially when code reviews take days to complete.

For optimum CI/CD performance, there should be at most three branches with lifetimes no longer than a day before merging with the trunk. But in most software development environments, this is virtually unheard of.

Pull request reviews that take days or weeks have significant cost implications. Besides work backlogs, delayed reviews can trigger complex merge conflicts. Even worse, pull requests come before integrated testing in the CI/CD pipeline, so a successful review doesn’t guarantee a similar outcome later.

The solution to these bottlenecks in the pipeline is continuous merge.

Continuous Merge Definition

Continuous merge is a set of processes that help eliminate the bottlenecks plaguing pull requests and code reviews.

The standard practice for engineering projects is to manage the code base through a version control system (VCS), where developers and contributors can collaborate.

It’s common for VCS repositories to have one or more branches, and in traditional PR reviews, changes to the code require manual checking before merging into the main branch.

Understanding Why Continuous Merge is Needed

A typical code review involves a contributor or developer opening a pull request and informing other collaborators that code changes have been pushed to a branch and require reviewing (and subsequent approval) before merging into the main branch.

PRs enable collaborators, typically lead or senior developers, to check the changes for quality adherence and then take one of these three actions:

Comment on the proposed changes.
Approve the changes.
Request further changes before merging the branch.

Many, many inefficiencies characterize this process, often resulting in PRs taking longer than is ideal. For example:

The collaborator may begin reviewing the PR only to pause prematurely to attend to other responsibilities.
The process freezes because developers don’t get feedback, nor is the merge executed.
If the repository has many branches with multiple contributors, the entire CI/CD pipeline may be affected, introducing the risk of merge conflicts and reduction of developer productivity.

Other issues that slow down traditional reviews include:

PRs being too long;
Overwhelmed teams;
Diversion of collaborators to other tasks; or
Sub-optimal assignment of PRs to people, such that the desired outcome is not achieved in the initial request.

Many gaps in this process necessitate re-engineering the PR review process to eliminate such inefficiencies.

How Continuous Merge Creates Frictionless Code Review

A pull request, also known as a merge request, is where developers or contributors indicate that code changes are ready for merging into the project’s main repository. It is an industry standard practice for other developers, team leads and other parties to review code changes before merging, human input into this process is inevitable.

Historically, this pull request process has caused inefficiencies, particularly review delays, as the process is not automated, so speed depends on the availability of the right code reviewer.

Continuous merge seeks to improve the pull request review process by introducing a layer of automation that enables automatic approval and efficient routing of complex pull requests to relevant reviewers.

Continuous merge considers the unique characteristics of individual pull requests and routes them appropriately on a risk-based model, ensuring process optimization and bottleneck reduction.

Continuous merge categorizes pull requests and code reviews according to their characteristics — type, code complexity, and size.

This creates automatic pull request lanes that boost merge speed and efficiency.

The 3 Crucial Steps to Continuous Merge

Step 1 - Provide Context to Pull Requests that Make Them Easier to Pick Up

The first step is to understand the context of the pull request. Pull requests are treated equally by most version control systems, which provide the same information for each one — not enough for a reviewer to assess their size or complexity.

Continuous merge adds a contextual layer with more information, like the estimated review time, the concerned project component, and the pull request owner.

Step 2 - Treat Pull Requests Differently Depending on Their Size and Characteristics

The second step involves classifying pull requests according to this contextual information. This process acknowledges that pull requests vary in size — some are just a few lines of code, and others are chunky. Despite this, pull requests go through a similar process, and even those that could be completed quickly may extend for days before the review.

The routing step of continuous merge seeks to remedy such inefficiencies by relying on PR classification to send pull requests with a few lines of code for near-instantaneous reviews and approval. The WorkerB Chrome extension for pull requests simplifies creating and delivering context-enriched pull requests to code reviewers.

Step 3 - Streamline Pull Requests with Low Risk

The third and final step of continuous merge is to apply rule-based automation and tooling to achieve automatic approvals and merges for low-risk pull requests while optimizing the routing of others based on their level of risk.

Why Continuous Merge Beats Traditional Merge

The traditional merge workflow involves strictly defined steps with all pull requests — whether five lines or a critical change of 100 lines — processed the same way.

Similarly, changes to static files, which can be approved and merged automatically, are processed through the same pipeline. When code reviews are delayed for days, there’s a greater risk of merge conflicts, and idle time between pull request reviews can lead to a drop in developer productivity.

Continuous merge, in contrast, addresses these CI/CD pipeline bottlenecks by contextualizing PR requests and classifying them via a model that has been defined by the team. And following standard DevOps practices, pull requests are placed in appropriate lanes for continuous merge through automated tools.

How to Easily Implement Continuous Merge on Your Team

New tools are emerging to support continuous merge and combat CI/CD bottlenecks.

gitStream helps you implement continuous merge.

gitStream deviates from the standard code-review process by automating merge approvals for small, low-risk pull requests and routing other types of code change to appropriate reviewers.

The tool uses a rule-based automation model that empowers both developers and reviewers.

Continuous merge also tries to ensure that the reviews go to the most appropriate people, so there needs to be thought given to the type of code and who is assigned to review it.

You can create automation rules in a .cm file to provide parameters and constraints that dictate how code is reviewed and subsequently merged. This file improves PR classification, allowing reviewers to gain more context on the PR request, so they can prioritize reviews according to characteristics like complexity and size.

Here’s an overview of how gitStream delivers continuous merging through the rules specified in the .cm file:

Auto-approval of pull requests containing small code changes that have passed unit testing successfully
Automatic assignment of pull requests to appropriate individual reviewers according to code complexity, estimated review time, and reviewer expertise
Automatic assignment of pull requests containing critical changes to the ideal review teams through the codification of custom rules

Getting started with gitStream is straightforward because the tool integrates seamlessly with your remote repositories. To set up gitStream on GitHub, for example, you can follow these three simple steps.

The .cm (.cm/gitstream.cm) file enables custom automation constructs, including defining context variables, filter functions that can be called on the context variables, and automation actions triggered when all conditions (rules) are satisfied.

The gitStream engine runs the custom automation defined in the .cm file. The engine supports some common actions, including add-comment, add-label, add-reviewers, approve, merge, set-required-approvals, and require-reviewers.

Continuous Merge Completes the Promise of CI/CD

Traditional PR reviews and merge workflows tend to create bottlenecks in the CI/CD process.

Code reviews and approvals can cause delays for days, even when some are low-risk and could be resolved quickly. Because all pull requests are processed the same way, improvements to the efficiency of this process have yet to be made.

Continuous merge is a promising solution to these challenges. With continuous merge, developers can create custom rules to accompany their pull requests, optimizing the review process.

Check out this talk from our Director of Developer Experience, Luke Kilpatrick, to learn more about continuous merge and and gitStream:

Want to cut code-review time by up to 40%? Add estimated review time to pull requests automatically!

The good news is that they found these delays could be eliminated largely by adding estimated review time to pull requests!

Learn more about how gitStream is making coding better HERE.

The easiest solution to code review bottlenecks? Estimated review time on pull requests

LinearB — Mon, 21 Nov 2022 23:29:43 +0000

TL;DR

The pull-request review process is a pain. Data shows this is a major bottleneck.
Pull-request review speed & quality can be improved by adding context to pull requests, like estimated time to review
Review automation tools like gitStream can add context for reviewer

Data shows an insane bottleneck in code reviews

The code review and pull-request process continues to be a major bottleneck for developers and dev teams. In a recent study, LinearB inspected ~1,000,000 PRs and found the following that: Pull requests are waiting on average 4+ days before being picked up.

Studies show pull requests & code review pickups are the no. 1 bottleneck in cycle time

Although there have been significant gains in coding times and deployment times; the amount of time it takes to start a pull-request review and the amount of time it takes to complete a pull-request review continue to disappoint.

The good news? There are things we can all do to break this bottleneck.

Context that allows developers to easily pick up pull requests is a game-changer

One key – and there are many keys – to improving both pull-request review speed and quality is providing as much up-front context to the reviewer as possible.

Examples of context proven to improve pickup time:

Estimated Review Time
Labeling low–risk changes like Documentation or Test changes only
Labeling high-risk changes like Core services, API Database or, Security
Ticket or Issue links
Test-coverage impact

What happens when estimated time of review (ETR) is added to pull requests?

Plain and simple: When a pull requests is labeled with how long it will take to review it - be it 5 minutes or 60 mixtures - developers:

Are more likely to pick up pull requests quickly
Are more likely to have have their reviews completed quickly

The longer a developer assumes a code review will take, the longer they will take to respond to it.

Why do pull requests with ETR get picked up faster and reviewed quickly?

Developers are knowledge workers, not cogs in a machine. By simply adding estimated time to review, you accommodate cognitive biases we all have. Specifically,

Knowing the review time allows the reviewer to schedule the best time to start the review. The key is to find a time that allows for non-interruption.
Cognitive reload occurs when a PR review is started and then not completed typically due to interruption. This causes a cognitive reload for the reviewer, starting the review over close to the beginning and extending the review time.
Conversely, the review can be rushed at the expense of quality. Fitting a 30 minute review into a 15 minute window results in quality gaps.

Two ways to add ETR to your pull requests

Create a template standard like this; or
Use PR Review Automation like gitStream, see below

To get started you need to install gitStream on your repository from GitHub marketplace. https://docs.gitstream.cm/github-installation/ and add 2 workflow files to your repo:

gitstream.cm;
github action file.

The default "gitstream.cm" file has estimated time to review already setup for you, but let’s dig into it a bit to see what it’s actually doing:

automations:
  estimated_time_to_review:
    if:
      - true
    run:
      - action : add-label@v1
        args:
          label: "{{ branch | estimatedReviewTime }} min review"

Let’s look at this snippet of yaml in the gitstream.cm file. "automations" keyword sets up the listing where all your automations will live and you can have an unlimited number of them. The next line is where you name your automation, in this case it’s "estimated_time_to_review," which will add an estimated time to review label on every PR run through gitStream.

Next is our conditional, in this case we just need it to be true, but you can use regular expressions, line counts and a lot more here to check the code in the pr and then act on it.

After the conditional, we need to run some actions from the conditions being met.

In this case, we run the add-label@v1 action which will add the label to the PR based on the arguments we give it. In the arguments (args) we provide a string that adds in the estimated time to review as the label to the PR.

How does gitStream determine ETR?

The estimated review time is predicted using a machine-learning model developed in LinearB and trained on millions of PRs. It incorporates features including:

The size of the PR, including details of additions, deletions, etc.
The file types that were modified, and the extent of the changes on these files
The codebase (repository) involved, and the familiarity of the PR issues with the code base

The review time prediction is then bucketed into a useful time range (e.g. 15-30 minutes) to provide the final estimate

Now that we have our estimated time to review, let’s mark what type of PR this can be. Let’s do this by adding some color to the labels.

We can also apply color coded labels providing a visual cue to help reviewers, let’s also add some code to hold state for the estimated time to review so it updates. The code below adds this functionality. By adding the "calc" we can get the updated estimatedReviewTime as it is updated per this branch.

automations:
  estimated_time_to_review:
    if:
      - true
    run:
      - action: add-label@v1
        args:
          label: "{{ calc.etr }} min review"
          color: {{ 'E94637' if (calc.etr >= 20) else ('FBBD10' if (calc.etr >= 5) else '36A853') }}

# To simplify the automation, this calculation is placed under a unique YAML key.
# The result is assigned to `calc.etr` which is used in the automation above.
# You can add as many keys as you like.

calc:
  etr: {{ branch | estimatedReviewTime }}

Now you know how to add context to your PRs with gitStream, this article just scratches the surface of what is possible, please check out the gitStream docs to learn more.

In future posts we’ll dive into using gitStream to do code review automation and having gitStream help find the right reviewers for your PR with reviewer automation.

Setup /:\ gitStream on your GitHub Repo today! Learn more here

How Reprise Stopped Engineering Bottlenecks Using LinearB

LinearB — Sun, 09 Oct 2022 19:04:27 +0000

Reprise helps businesses create demos of their products without needing to code. But like any no-code platform, there’s actually a lot of programming going on behind the scenes. Reprise needs to be able to develop their platform efficiently if they’re going to make it as easy as possible to use.

We spoke with Jennie MacDougall, Reprise’s Director of Engineering, to see exactly how they were managing that.

Work remotely, without worry

As Reprise is a fully remote team, it’s especially important to know how individuals are getting on. When a team leader needs to check the progress of a task, they don’t want to call around to every single individual. They need that quick overview to be able to make their decisions. For that, Jennie explains, the Pulse feature of LinearB can help you keep track of your team.

“Being able to see at a quick glance how effective engineers are, what they’re working on, or how much work they’re getting done in a two-week sprint is super helpful,” she explains.

On the flip side, engineers need to be kept up to date too. For this, Reprise uses our Slack add-on WorkerB to automatically keep their teams in the loop. Instead of their engineers needing to ping their teammates to look at PRs or recheck that code is moving through the pipeline, they now get all those messages in the same place as they see the rest of their notifications.

Cut coding times and scale faster

Coding anything takes time. But there are often a lot of inefficiencies in the process that can stall development. For Reprise, they use the cycle time metrics that we provide to help spot any problems in that process, particularly the coding time, pickup time, and review time. This helps them be able to spot and fix different bottlenecks on different teams.

Get context around cycle time bottlenecks in one click. Diving into your data has never been this easy. Get started with our free-forever account today!

“Most organizations probably look at it from an engineering standpoint of the entire team,” Jennie says. “But all the teams are made up slightly differently. So figuring out how to deploy resources as needed and where folks might be stumbling is really easy with the cycle time breakdown per team.”

This also means that they can see when they need to hire new team members. For example, they can keep track of the cycle time as the team grows to spot when it is starting to get too unwieldy and large. Or they can spot trends across all their teams and find opportunities to break out a new team.

Automate grunt work so devs can focus on great work

In their own way, processes that can be automated are in and of themselves bottlenecks. Why? They take developers' focus and problem-solving skills away from coding to tasks that are necessary but in no way require a knowledge worker to do.

"Anything we can automate, we try to do," says MacDougall. "We use LinearB to automate a ton of reports so I don't need to be measuring velocity all the time!"

To paraphrase Jennie, LinearB's tools for automation allow you to focus more on the important stuff and less on the fluff.

Start being more efficient

If you’d like to make sure that your sprints are efficient and effective, we can help you keep track of your own cycle time and begin improving your process.

In fact, over 80% of LinearB customers have seen month-over-month reductions in cycle time. Plus, you see results fast -- with reductions happening within the first 120 days of LinearB adoption.

Start improving with LinearB. Sign up for our free-forever plan or get a free trial of our full product. Get started today.

You’re invited to Interact on October 25th!

Want to know how engineers at Slack and Stripe connect their dev teams’ work to the business bottom line? Or how team leads at Shopify and CircleCI keep elite cycle time while minimizing dev burnout and maximizing retention?

These are just two of the topics we’ll tackle at Interact on October 25th.

A free, virtual, community-driven engineering leadership conference, Interact is a one-day event featuring over 25 of the most respected minds in development, all selected by the thousands of engineering leaders in the Dev Interrupted community.

Register now!

Solving the Next Engineering Challenge: Continuous Merge

LinearB — Sun, 25 Sep 2022 22:07:40 +0000

The adoption of CI/CD tools has made delivering new features to customers faster than ever. A far cry from the weeks-long code freezes and everlasting pipeline stabilization sessions that my team commonly referred to as integration hell.

But yesterday’s solutions have exposed the next big challenge for today’s developers; actually getting code merged.

How We Got Here

The ‘90s were a unique time in the history of software development. Projects would often take six months to complete, and compared to today’s standards, it was a black box operation. Feedback in a pre-agile world was no small thing. It meant design meetings, architecture changes, and infrastructure development to say the least. And on top of all that, it came with a large side of customer expectation.

“It would have been nice to know about these needs before we built the damn thing to work like this,” was a very regular thought of mine. The need for a feedback loop, shorter iterations, and less siloed work was rapidly exposed.

Then in 2001 the Agile Manifesto came out, forever changing the way software was developed. As agile began taking hold in the industry, customer expectations continued to grow. Using scrum vs traditional waterfall, we were able to develop faster than our counterparts in ops could deliver. This speed divergence between development and operations exposed another major challenge, building a faster delivery pipeline.

With this need to speed up the delivery pipeline, CI/CD automation and the DevOps movements came to be in the early 2010s. This automation opened the door for new architectures like microservices, integrated security, and GitOps to evolve how software is built and delivered. Each of these advancements promised the same two things: a faster, more reliable delivery pipeline and more time to code for developers. Unfortunately the “more time to code” part never happened.

Unlocking Developer Productivity

Developers today are more weighed down by non-coding activities than ever before. A recent study by Clockwise showed that developers only have 20 hours of focus time per week. The good news is that businesses are beginning to understand the cost of developer toil and implement real changes to counteract it.

The developer experience (DX) movement has started gaining traction with major tech companies like Netflix, Airbnb, and Meta adopting developer productivity roles. Major publications like Forbes and Fast Company are publishing developer experience & productivity articles. Tech researchers like Nicole Forsgren at GitHub are publishing new measurement frameworks like SPACE.

The ultimate goal of the DX movement is to improve developer happiness and as a result productivity. But how do you measure something as complicated as productivity? How do you baseline happiness?

Critics of the movement are quick to tell you that it’s nigh impossible to accurately measure such subjective areas as productivity or happiness. They’ll tell you that in doing so you will only ruin what you’re trying to preserve, developer culture.

I agree with them…to a point. It’s true that developer satisfaction surveys and tracking team velocity are unlikely to help retain engineers. But that doesn’t mean trying to improve the developer experience is a fool's errand.

The Merge Frequency Problem

When I was a developer, I felt the most satisfaction when I could complete a task. That meant merging code to the trunk, or better yet getting it deployed, and starting to work on something new with a clean slate. It was always worse having my work blocked for days without review than it was having a regular stream of meetings. Every hour that my work sat unattended I lost more momentum and became increasingly frustrated.

My happiness and satisfaction as a developer was always based more on solving interesting problems, helping others, and shipping code than it ever was on velocity. If the developer experience movement is truly focused on improving developer happiness, then it’s time to focus on letting us actually get our code merged.

We analyzed millions of PRs from thousands of dev teams across all sized organizations. We found that the average cycle time is about 7 days.

My company’s data analysis team, LinearB Labs, has spent the last 3 years looking at cycle time (aka lead time for changes), the time it takes from when coding begins to when it’s deployed. After analyzing millions of PRs from thousands of dev teams across all sizes of organizations, we found that the average cycle time is about 7 days.

But what is really interesting is that the code or PR in this instance sits in the PR review process for 5 out of the 7 days. Even worse, we found that the majority of those 5 days resulted in an “LGTM” type review.

I speak with engineering leaders from companies like Stripe, Slack, Google, Netlify, and more every week on the Dev Interrupted Podcast; we hear the exact same story over and over. The PR review cycle is the main bottleneck they have to overcome. They also tell us another truth: that if the code someone wrote, assuming it was properly tested, is released soon after it is written, there is a better chance of catching a problem while it is still fresh in the developer’s head.

All of the data, both qualitative and quantitative, is telling us that the next major problem in the history of software development is focused on getting code merged. I believe it is time we start making moves toward a continuous merge future.

3 Iterations of Continuous Merge

v.1 Context

Scenario: I’m working on an issue, and I get an alert that someone assigned me to review their PR. But I don’t really know anything about that PR, so I continue working on my issue and plan to come back to the review later. When I get to the review, I need context, and by the time I actually start reviewing the PR, the other developer is hard at work on something else. I may have to break their focus and get information from them, forcing both of us into unnecessary context switching.

So the first problem we decided to solve was context.

Using our Slack and MS Teams bot, WorkerB, as the vehicle for PR alerts, we started by simply enriching PR notifications. Instead of, “You’ve been assigned this PR to review,” we now provide our users with:

Estimated Review Time^
Associated project issue
The PR owner

^ based on a proprietary learning algorithm

Each of these three pieces of information empowers the developer to make a better decision about when to pick up the review. It answers questions like: Do I have enough time for this review during my next small break or should I queue it? Is this a priority project? Do I owe this person a favor?

Continuous merge isn’t solely about improving the speed to merge. It’s about giving developers the tools and information they need to make better decisions and reduce the cost of PR context switching on them.

v.2 PR Routing

Not all PRs are created equal. Continuing our data analysis, we found that many PRs are incredibly small, while others are much larger. Shocker, I know. Yet they both go through the exact same review process.

Even more so, the small PRs that would wait for days to be reviewed would result in a “Looks good to me” type comment 80% of the time. Why are we waiting days to merge an LGTM PR?

Again we utilized WorkerB to begin routing PRs with <5 lines of code changes into Slack and MS Teams for immediate review and approval. This simple, yet needed, feature takes a snapshot of your PR changes, and sends them via DM to the assigned reviewer so they can approve almost instantly.

It’s important to stress here that our v.2 solution is the first time any PR has been treated differently based on it’s unique characteristics. This feature was a hit with users. We found that we were able to route 11% of all PRs for an almost-instant approval. So we began to extrapolate into v.3.

v.3 gitStream

Iterations 1 & 2 taught us that empowering developers with more information allowed them to make better choices with their time. It also proved that we could increase merge frequency by routing PRs based on their characteristics. Knowing this, we started working on the first stand-alone continuous merge tool, gitStream.

Learn more now!

Creating new technology is one of the great pleasures of working in the software industry. Spending late nights with passionate people playing the “what if” game.

What if we could automatically route every PR to a more specific place?
What if we created automations in the repo that could tell people where PRs would be routed?
What if the repo owner could create any automated path they wanted?
What if we could give the developer context into which review automation a commit falls into while coding? 8 What if we change the very nature of the PR process today…

CM/CI/CD

Continuous merge (CM) is a rules-based approach to merging code from an individual developer into the team branch with the level of review reflecting the importance and risk of the code being merged.

In more plain terms, a repo owner can create review automations for the repo (e.g. automatically approve PRs if only image files were changed), and the developer will use an IDE integration to tell them which “lane” their PR will fall into. These repo-based review automations and IDE context do two things:

Eliminates the “standard” PR review process in lieu of routing PRs based on their characteristics.
Encourages high-frequency merge behaviors from developers by adding context during the coding process.

The tool we’ve created that automates the continuous merge process is called gitStream.

Continuous merge using gitStream starts with the .cm file to create the review automations for your code. Not all pull requests are equal. Some PR’s are just image or docs changes; while others are modifications of key parts of the services that need special attention. Each of these unique cases are defined in your .cm file, communicating to the developer how to make the code they’re writing qualify for a given level of review.

By using gitStream and having well-defined automations, additional context, and a clear record of changes, several cycles of back and forth are saved and merge velocity is drastically increased.

Get Early Access to gitStream

I'm happy to say that gitStream, the first continuous merge solution is in beta and we’re accepting early sign-ups today at gitStream.cm.

Learn more now

Over the next couple of months, as we build, test, and iterate, we hope you will begin to think about what review automations you would want to add to your repos. Even better, sign up for early access and help us test gitStream.

How might you improve the quality of a review by routing it to a specific person or team?
What types of PRs can be auto-merged?
What types of review automations would you want to enable for the entire company?
How would back-end team review automations be different from front-end team ones?

The automation of continuous merge has an almost unlimited scope. I hope you will join us on our journey as we change the very definition of how software is created and delivered…all over again.

And if you want to learn more about continuous merge, check out an in-depth discussion with my co-founder, Ori Keren, on the Dev Interrupted podcast.

You’re invited to Interact on October 25th!

These are just two of the topics we’ll tackle at Interact on October 25th.

Register now!

How Dama Financial Improved Cycle Time With LinearB

LinearB — Sun, 14 Aug 2022 22:02:00 +0000

Plain and simple: If your engineering team’s cycle time - the amount of time from work started to work delivered - is too long, nothing else really matters.

Customers won’t get their features, sales teams can’t deliver on promises and the entire business outside the engineering department will fail.

This is why cycle time and breaking its components down into manageable chunks that can be improved, is at the heart of what LinearB does.

We took some time to talk to Zach Goldberg, CTO of Dama Financial to learn how management, teams and individual contributors all use LinearB to improve cycle time.

Let leaders know cycle time, all the time

At the CTO and director-level of engineering, the most important thing you need to be able to do is have ready access to what people are working on and when it will be done - in short, the health of your cycle time.

In his search to get a handle on the effectiveness of the org he oversees and how it connects to business outcomes, Zach Goldberg and Dama Financial landed on LinearB.

“I am very interested in cycle time, as a whole, across the team” explains Zach Goldberg on how he thinks about cycle time as a director.

“[I need to know] how long it takes us to go from idea to specification to release to a customer. LinearB is crucial in the back half of that cycle (everything after the idea).”

Help engineers make the decisions that reduce cycle time

The four major components of cycle time are: 1) Coding time; 2) Pickup time; 3) Review time; and 4) Deploy time. The actual time it takes to complete these is the sum of a host of behaviors, decisions and practices done by individual developers.

LinearB is designed to make sure that each of these individual behaviors is optimized in ways that brings the time down in each - a point Zach says has been crucial in engineers taking control of cycle time and bringing it down on their own.

“We’re constantly coaching [engineers to make] small pull requests, small commits… to keep things moving” explains Zach. “As a tool for improving behaviors and habits on a day-to-day basis, LinearB is always brought up.”

Get context around cycle time bottlenecks in one click. Diving into your data has never been this easy. Get started today!

Helps managers quantify the quality of work

Most team leads or managers were elevated to that position because they were great at coding, not because of their specific management skills. LinearB has been key in helping these engineers get crucial performance information that they didn’t know they needed to run effective teams.

In short, LinearB has been a crucial tool in helping the next-gen of managers concretely grasp metrics that help them understand their teams and bring their cycle times down.

“Most managers I speak to don’t think about quantifying performance. It’s still a really difficult thing” explains Zach. “As a tool to make sure we’re all growing in the same direction or thinking about performance in a similar way, LinearB is helpful across the organization.”

“[Having] the same metrics from the same tool is super helpful.”

Cycles of success…

The good news for you? Zach and Dama Financial’s experience with LinearB isn’t the exception: It’s the rule. Over 80% of organizations who adopt LinearB see these cycle time and performance improvements – with business-changing results coming in under 120 days of implementation. For more information on how LinearB can help your team improve cycle time as well as a host of other performance metrics, check out LinearB's guide to improving your engineering metrics.

You’re invited to Interact on October 25th!

These are just two of the topics we’ll tackle at Interact on October 25th.

A *free, virtual, community-driven engineering leadership conference*, Interact is a one-day event featuring over 25 of the most respected minds in development, all selected by the thousands of engineering leaders in the Dev Interrupted community.

Register now!

Engineering Metrics Benchmarks: What Makes Elite Teams?

LinearB — Mon, 02 May 2022 22:29:18 +0000

DORA Metrics and Beyond

In 2014 the DevOps Research and Assessment (DORA) team published their first State of DevOps report, identifying four metrics that can be used to measure engineering team performance.

Six months ago the Data Science Team at LinearB decided to continue where DORA left off, digging deeper into the data than ever before. For the first time in history, engineering teams are able to benchmark their performance against data-backed industry standards.

Our study analyzed:

1,971 Engineering Teams
847K Branches

The Engineering Metrics Benchmarks chart was created from a study of 1,971 dev teams, and 847k branches over a four-month period.

Benchmarking your organization’s performance against these metrics is a great way to understand the efficiency and effectiveness of your engineering operation. The best way to begin your journey is by gathering data.

To help you generate these nine metrics for your team, LinearB provides free accounts for dev teams. Our platform correlates data from your GitHub, GitLab or Bitbucket repos with data from your project management tool, like Jira, to provide the most accurate picture of your team’s performance possible.

Throughout the rest of this document, we will be providing details into how we calculated each metric, why we made the choices we did, and how each metric can be used to improve your engineering organization.

Calculating Engineering Metric Benchmarks

While the DORA Metrics and Accelerate book are based on interviews and assessments, the Engineering Metrics Benchmarks are based solely on data from working dev teams. The data itself comes from the many thousands of free and paid users of the LinearB platform. Our data is trusted because it comes from a global population of engineers who are improving their engineering metrics in a variety of ways. Since the LinearB platform is flexible enough to allow users to track their work through Git, project management, API or all three, our overall data sets are more diverse and therefore a better representation of how engineering teams work in real life.

When we began our study, we had to decide on what data was best suited to provide us with trusted results. So we started by making a list:

We will not take out outliers
We will only measure Merged PRs
Will only include organizations with at least 400 branches
We will only include organizations that had 270 days worth of data
We would exclude draft PRs and excluded branches from our calculation

With these rules applied, we started by taking the average metric value during a 270 day period and began plotting them on a graph. Once this was done, we were able to take the percentiles that would turn into our rankings.

Top 10% – Elite
11 – 30 % – Strong
31 – 60% – Fair
Last 40% – Needs Focus

Why did we use these percentiles? It was a question we struggled with during the study. Why not make Elite the top 20% and make everyone feel a bit better about their performance? Should we make Fair and Strong a little bit larger so more organizations land in the middle of the chart?

At the end of the day, we wanted to represent what we felt was most true to the spirit of the data. In this regard, that meant Elite should be truly special. And any metric that falls into the last forty percent should be focused on by the organizations to understand how it can be improved.

Engineering Metrics

The nine metrics shown in the chart are all indicators of an engineering organization’s level of quality and efficiency. Teams who use these metrics to identify areas for focus, set goals and take steps to improve significantly increase their business value delivery.

Cycle Time:

Measures the amount of time from first commit to production release. It is a metric borrowed from lean manufacturing, and it is one of the most important metrics for software development teams.

Short Cycle Time demonstrates that an organization is delivering value to customers at a faster rate. Short Cycle Time correlates to small PR sizes, a healthy review process, and high deployment frequency. Overall, teams with an elite Cycle Time are able to deliver more features predictably and at a higher quality.

Long Cycle Time is caused by multiple reasons, the most common being bottlenecks within the PR review process. Longer Cycle Times reduce team efficiency as well as the ability to deliver features predictably.

Coding Time:

measures the time it takes from the first commit until a pull request is issued.

Short Coding Time correlates to low WIP, small PR size and clear requirements. Combined, these benefits mean a reduction in developer context switching costs (i.e. time spent re-focusing on a task).

Long Coding Time correlates to larger PR sizes, longer PR Review Times and a reduction in code quality. When requirements are unclear or work isn’t broken down into small chunks, code becomes more complex and more challenging to review thoroughly before production.

Pickup Time:

Measures the time a pull request waits for someone to start reviewing it.

Low Pickup Time represents strong teamwork and a healthy review process. When a PR is picked up and reviewed within 24 hours, the code is still fresh in the mind of the developer. This reduction of cognitive load saves a significant amount of refocus time.

Long Pickup Time is an indication of a common workflow bottleneck. Either the team isn’t aware a PR is ready for review or there aren’t enough developers taking on reviews. In both instances, a longer transition time between handoffs correlates to higher cognitive load (re-focus time) and reduced efficiency.

Review Time:

Measures the time it takes to complete a code review and get a pull request merged.

Low Review Time correlates to small PR sizes, reduced code complexity and short Cycle Time. The caveat here is to make sure your Review Depth (the number of comments per review) is consistent between two and four.

Long Review Time indicates large PR sizes, a lack of focus time and/or quality issues. Regular interruptions during a large PR review increase Review Time due to the developer needing to “get back into” the task. In a similar light, the longer a PR review takes, the less fresh the code will be in the mind of the owning developer. High rework rates also correlate to long review times.

Deploy Time:

Measures the time from when a branch is merged to when the code is released.

Low Deploy Time correlates to high deployment frequency and a more stable production environment. Modern development practices like CI/CD and automated testing improve the time to production and the feedback loop from users.

High Deploy Time correlates to manual efforts and low code quality. Build failures can be reduced by standardizing small PR sizes and a thorough PR review process.

Rework Rate:

Measures the amount of changes made to code that is less than 21 days old.

Low Rework Rates are an indication of higher overall code quality and a strong PR review process.

High Rework Rates signal code churn and is a leading indicator of quality issues.

Planning Accuracy:

Measures the ratio of planned work vs. what is actually delivered during a sprint or iteration.

High Planning Accuracy indicates a high level of predictability. Predictability within a sprint or larger project allows teams to deliver what they promised to deliver, on time.

Low Planning Accuracy is an indication of unplanned work, shadow work and high code churn. Missed delivery deadlines and high carryover are the most common result of low planning accuracy.

Using LinearB’s Project Delivery Tracker can help you visualize unplanned work your team is doing each sprint and improve your planning accuracy. Book a demo today!

Deployment Frequency:

Measures how often code is released.

High Deployment Frequency represents a stable and healthy continuous delivery pipeline. Elite development teams are deploying small chunks of code to production multiple times a day to improve the user experience and shorten the feedback loop.

Low Deployment Frequency is an indicator of large deployment events that increase the likelihood of production instability.

PR Size:

Measures the number of code lines modified in a pull request.

Small PR Sizes are easier to review, safer to merge, and correlate to a lower Cycle Time.

Large PR Sizes directly correlate to higher Cycle Time and code complexity. High PR sizes are the most common cause of a high Cycle Time.

Understanding your team’s current performance is the first step to creating a culture of continuous improvement. If you’re ready to discover how your team performs against industry standards today, use this link to book a free engineering metrics benchmarks consultation.

Those “Pesky” Pull Requests are Totally Worth It

LinearB — Mon, 12 Jul 2021 18:29:04 +0000

Pretty much everyone does code reviews. They’ve been around a long time. I remember back in my Borland days when the Chief Scientist would come in every morning and review all the code that had been checked into the Subversion(!) repository the previous day and send emails out to folks whose code wasn’t up to snuff. That’s old school.

Slightly less old school? Saving all the check-ins up until Friday for the Dev Leads and/or Dev Managers to review and approve. Both of these techniques leave a lot to be desired -- the main thing being a complete lack of interaction between the developer, the code, and the reviewer.

Code Reviews have a number of purposes. Probably the most important one is preserving the quality and integrity of the code in the repository. Even the two old-school ways above do that.

But almost as important as the learning opportunity that code reviews can provide. If the only feedback a developer gets from a code review is mistakes in formatting or other trivial things like that, then nobody learns and gets better. The old school ways above provide for few opportunities for a developer to increase their skills.

To provide learning opportunities, code reviews evolved into meetings where everyone looked at the code written that week and commented on it, criticized it, or otherwise ran it through the gauntlet. This did provide a learning opportunity for developers, but it took more time, as it was 100% synchronous and required all code to wait for the next scheduled meeting to be reviewed.

Now, almost no one is doing these old-school code reviews anymore. All the cool kids are doing pull requests. (Some folks call them “merge requests.”) Pull requests have a number of advantages over the previously mentioned methods, including:

Being done completely asynchronously, but in public, for all to see.
No one needs to wait to review the code -- it can happen almost immediately after a pull request is issued.
A history of all the comments stays with the code in a repository. This allows a developer to come back to the code a year later and see all the thought that went into writing it.
Pull Requests can be tracked, monitored, and measured. A whole lot of good things can come out of that.

Should you do code reviews at all?

Interestingly, some say no, you shouldn’t.

Not only is Jessica Kerr a great speaker and a good Twitter follow, but she also has some interesting ideas about code reviews in her article of March 27 entitled "Those pesky pull request reviews." In fact, she doesn’t like pull requests, and argues that you should sidestep them by just working on a given task as a team so that everyone sees everything as the work gets done.

She believes that pull requests work great for open source projects where a “team” is really a set of individuals coordinating work together. For true development teams, she believes that if a team all works together on a single task, everyone learns and understands the code, and thus there is no task switching between coding and doing pull requests because the pull requests are unnecessary.

Jessica’s idea is radical -- basically going beyond Pair Programming and moving into mob programming. Mob programming is the idea of having whole teams work together on projects in serial rather than individually in parallel. Mob programming can eliminate the need for pull requests by causing all of the communication and learning to take place during the coding phase, without any review.

Not a Fan

I’m having a hard time agreeing with her idea for a couple of reasons:

The transaction costs are too high. It seems to me that having four people work on a project together makes for many communication channels, increases the likelihood of interruptions, and reduces the amount of code that will actually get written. It’s sort of a “Too many cooks spoil the broth” notion.
It doesn’t capture the discussions and history that will remain long after the code is committed. One of the most important and powerful benefits of pull requests is the learning that can take place during and even long after code has been reviewed and deployed.
Not all projects are conducive to multiple team members working together. Some are small and multiple people working together would be overkill. Some are esoteric and require the focus of one person. Some will match the team and can be worked on together. There’s no one size fits all solution for all projects.
Finally, not doing pull requests pretty much eliminates all the benefits of metrics systems like LinearB. Tracking the progress of pull requests and code reviews through the pipeline is a critical process for knowing how your team is performing. Without that, you can measure things and if you can’t measure things, you can’t improve.

As part of a discussion about code reviews, Rob Kraft, one of the Development Leaders in our vibrant Dev Interrupted Discord Server (you should join!) made the following comment that I agree with:

I think that what Jessica needs is a good look at LinearB.

Let me address some of her more specific objections:

“Let’s face it: nobody wants to review pull requests.” Well, I don’t think that is true. We here at LinearB see customers every day that are doing pull requests efficiently and effectively. Sure, pull requests can be hard and nobody wants to do them if you aren’t correctly incenting the team to create pull requests that are easy to review. No one likes a huge pull request. But through monitoring metrics like Pull Request Size, you can encourage your team to create small, easy-to-review pull requests. And voila! People don’t hate pull requests anymore.
“They’re a social interaction minefield!” People complain that code reviews can cause strife on a team. Well, so can conversations during Mob Programming. I’m not sure that I see a distinction, And if doing a code review causes strife, then you have a cultural problem that no development methodology is going to solve.
“We could blame the people. We could nag them more. We could even automate the nagging!” Well, if code reviews are small, concise, and easy to do, “automating the nagging” via our WorkerB product is usually more than enough to get the ball rolling and keep it rolling. Notifications and tracking of any reviews that do happen to languish keep things moving as well. LinearB customers have seen drastic improvements in code pipeline productivity as a result of this so-called “nagging”.
“Maybe instead of trying to work a bit more together, we could work together.” Well sure, but if you do that, checking in code without a process of pull requests and code reviews, well, then you aren’t getting all the benefits listed above, nor those of a metrics tool that can show you what your Cycle Time is doing. And I don’t believe that mob programming will prevent the cultural problems that can arise from code reviews. People will be people whether in a mob programming environment or in an asynchronous code review process.

Bottom Line

Okay -- so what rubber is hitting the road here?

If pull requests and code reviews are hard and people don’t want to do them, then you are doing them wrong. So the trick is to make them easy to do.

We here at LinearB see many, many customers improve their Cycle Time and their overall software development process by using and tracking pull requests. By combining metrics tracking around pull requests with tools like WorkerB, many, many development organizations have seen smaller pull requests, better reviews, shorter Cycle Times, and an overall sense that things are really humming.

Monitoring things like the size of pull requests, when pull requests are assigned, picked up, and commented on, as well as monitoring the depth of reviews that take place all create an environment of small, discrete, easy to review pull requests.

And of course, if you want to find out more about what our customers already know, you can book a free demo of LinearB.

In the end, while her ideas are intriguing and thought-provoking, I can’t say I agree with Jessica’s argument. There doesn’t seem to be any good reason not to do pull requests with code reviews.

Jessica’s blog post can be read on her Jessitron blog and you can follow her on Twitter at @jessitron