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.
Table of Contents
- What Is GitHub Actions?
- What Is Code Owners?
- What Is gitStream?
- gitStream vs Code Owners vs GitHub Actions
- When to Use Each Tool
- Make Your Move on Merge
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/ @octocatWhat 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:
| Methods | Scalability | Risk | Efficiency | Customization |
| GitHub Actions | Moderate | High | Efficient | Some customization |
| Code Owners | Low | Low | Not efficient | Limited customization |
| gitStream | High | Low | Very efficient | High customization |
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.
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.
