Code Quality Metrics and Continuous Merge
Every software engineering team deals with their fair share of buggy code. In fact, more than one-third of developers dedicate 25% of their time identifying and resolving bugs – valuable time which could be better spent building new features. When code is well-structured and properly documented, it becomes easier for developers to improve code quality metrics and decrease overall cycle time.
What’s more, high-quality code is easier to scale as software evolves, allowing for easier integration of new features moving forward. In this guide, we’ll introduce the practice of Continuous Merge and how to start applying its principles to establish and automate merge standards in your organization that will strengthen your code quality metrics.
Want this guide sent directly to your inbox? Click here and enter your email!
What Is Continuous Merge?
Continuous Merge is the guiding practice behind how engineering organizations program their delivery pipeline. In essence, it’s a way of implementing workflows that optimize the pull request merge path for both velocity and code quality metrics.
Continuous Merge (CM)
The practice of automating the classification of pull requests in order to optimize the path to merge.
Continuous Merge isn’t just a category, it’s a mindset. And as teams adopt its philosophy and introduce pre-merge workflow automation into their processes, they benefit from higher software code quality metrics, adherence to compliance best practices, and fewer bugs.
Ultimately, adhering to CM practices will allow you to eliminate standard, or one-size-fits-all PR review processes, in lieu of routing PRs based on programmed automations. Doing so will allow your team to optimize their metrics for code quality.
The First Step Towards Continuous Merge
Most engineering organizations do not have the visibility or mechanisms in place to enforce or audit merge policy across multiple dev teams. And this inconsistency can give rise to inefficient processes, poor developer experience, increased context switching, and poor code quality metrics.
To take the first step towards Continuous Merge, engineering leaders should start by creating a set of merge standards on their team that will then be adopted as policy at the organizational level.
Merge Standards
A set of guidelines that standardize when and how code changes should be merged into a shared codebase.
Adhering to merge standards establishes best practices for code quality metrics in software development, facilitate collaboration, and boost efficiency.
Merge standards dictate the decision for “if” “then” scenarios. When practicing Continuous Merge, your merge standards should balance velocity with quality.
In this guide, we’ll break down the quality side of this equation. To read more about Continuous Merge and its many benefits, check out our Guide to Continuous Merge: Merge Standards.
The Benefits of Quality Merge Standards
Creating merge standards on your engineering team can significantly improve software code quality metrics in five key areas:
- Consistency: When all code changes follow a consistent style and structure, the codebase is easier to read and understand, ultimately giving rise to better collaboration and reducing the likelihood of bugs.
- Efficiency: Merge standards provide a clear set of guidelines for reviewers to follow. Now, engineers can focus on higher-level concerns, like functionality and architecture, rather than wasting their time on trivial issues like formatting or naming conventions.
- Early Bug Detection: By enforcing best practices, you can enable your team to spot bugs or issues earlier in the development process. Providing engineers with a merge standards checklist during onboarding will help ensure that they’ll habitually review code thoroughly before merging.
- Scalability and Maintainability: Merge standards promote practices that make it easier for your team to scale over time, while also maintaining a healthy codebase. Well-documented code, proper comments, and clear naming conventions all contribute to optimizing code quality metrics and their impact on software scalability.
- Knowledge Sharing: When everyone adheres to the same standards, it becomes easier for engineers to work on different parts of the codebase and to onboard new hires moving forward. Merge standards that are updated regularly help team members learn from each other’s mistakes and successes.
We suggest using the following merge standards as an example when creating your own, then customizing them to your team's processes as you see fit. From there, you can align at a higher level and reap the benefits of Continuous Merge.
It’s important to note that merge standards can vary widely org to org (and even team to team), depending on factors like company size, maturity, and methodology.
Merge Standards That Promote Quality
At LinearB, these are the merge standards our engineering team uses to boost our software code quality metrics:
Code Experts: Assign experts to review sensitive code
High-Risk Tag: Let DevSecOps take the reins on high-risk work
Missing Tests: Mark PRs without tests
2 Reviewers: Require additional reviewers for complex PRs
Deprecated API Alert: Request changes on deprecated APIs
Auto-Approve Sonar Clean Code: Automatically approve PRs that receive an 'A' rating from SonarCloud’s quality gate
Label SonarCloud Quality Reports: Get a comprehensive report from SonarCloud whenever vulnerabilities, bugs, code smells, or security hotspots are detected.
Review Sonar Duplications: Request changes whenever Sonar reports an excessive level of duplicated code.
Flag Sonar Security Alerts: Require additional reviews whenever a PR fails to pass a SonarCloud quality gate check.
Estimated Review Time: Add color-coded labels to PRs with estimated review time, so devs can prioritize their time accordingly.
Welcome Newcomer: Share a welcome message when a developer opens their first PR to a repo, and provide context to help them figure out what’s next.
Label Percent New Code: Post a comment that indicates what percentage of the PR is new code.
Flag Deleted Files: Label PRs that delete files.
Request Screenshot: If the PR lacks an image file, apply a no-screenshot label to request a screenshot.
Want this guide sent directly to your inbox? Click here and enter your email!
Implementing Quality Merge Standards with Policy-as-Code
Engineering teams have two choices when it comes to implementing merge standards: they can do so manually or they can leverage workflow automation.
Option 1: Manual Adoption
The first option, albeit time consuming and task-oriented, is certainly do-able.
To start, we recommend working with your team to evaluate your existing code merge practices. It can be helpful to ask questions like:
- When we collaborate well, what tend to be the reasons?
- What processes enable devs to get code out the door quicker?
- Which practices help us ensure healthy metrics for code quality?
Once you’ve aligned with your team on what’s most important to standardize, it’s time to create a comprehensive document outlining your team’s new merge standards. Feel free to pull from our team’s list (above) or create your own from scratch.
From there, publish your merge standards somewhere easily accessible, like on your team’s wiki, then conduct a training session to talk through best practices and address any questions or concerns. It can also be helpful to record this session for future hires to review during the onboarding process.
Moving forward, because these standards are subject – and even likely – to change, we recommend evaluating and updating your merge standards at least once a year.
Option 2: Workflow Automation
Alternatively, engineering teams have the option to use a Continuous Merge tool like gitStream to create policy-as-code that will automatically enforce your quality standards across all repos.
With gitStream, engineering teams can customize their code review workflows for each pull request, based on the content of the code.
Automating Continuous Merge practices using gitStream starts with a simple .cm file that programmatically defines how your PR process is managed.
Merge standards can help your organization automate the process of building code expertise, manage high-risk PRs, and flag situations where corrective actions are required.
Code Experts: Assign Experts to Review 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 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.
This way, the code expert can provide specific and informed feedback, rather than general comments that may be lacking vital context.
gitStream users can leverage this rule to:
- Identify the most knowledgeable and recently active developers to review code
- Distribute the review burden across teams to increase the overall level of expertise
- Automatically assign the best reviewer, thereby improving code quality metrics while decreasing developer toil
Developer Toil
The kind of developer work that tends to be manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows.
Code Experts can also be used as a replacement for simpler solutions like GitHub’s CODEOWNERS. 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.
High-Risk Tags: 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 engineers 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 the PRs containing those terms are reviewed by their team.
In the example above, a gitStream user has added a required label: Security. Doing so will route all PRs with this component to reviewers with write access – in this case, DevSecOps.
Missing Tests: 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.
Every developer appreciates added context on their pull requests – and gitStream PR labels come in many different shapes and sizes.
Here are 6 other ways you can add vital context with PR labels:
2 Reviewers: Require Extra Reviewers for Complex PRs
Historically, when engineering teams have wanted extra reviewers on a 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 certain reviews.
gitStream solves for this dilemma by allowing users to customize rules per repo, like assigning two reviewers for:
- PRs with 200+ code changes
- PRs opened by new team members
- PRs with high potential for security risks
- PRs that affect complex components in the codebase
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.
Deprecated API Alert: Request Changes on Deprecated APIs
The best managers are the ones who equip their teams with everything they require without nitpicking or micromanaging.
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 improve code quality metrics 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.
Enhance Quality Across The Entire SDLC
Workflow automation doesn’t have to stop at your Git provider – it can also be used to improve code quality metrics across your entire SDLC.
gitStream integrates with an entire suite of CI/CD tooling, including tools that:
- Boost Code Quality Metrics – SonarCloud
- Improve Documentation – Swimm and Jira
- Strengthen Security – Jit and Dependabot (Coming Soon)
Auto-Approve Clean Code with gitStream + SonarCloud
It’s a common misconception that engineering teams must sacrifice the health of their software code quality metrics 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’s integration with Sonar allows engineering teams with improving code quality metrics through automated testing.
Here are 4 gitStream x SonarCloud rules your team can leverage today to enhance your code quality metrics, while getting PRs out the door faster:
Fast-Track Documentation with gitStream + Swimm
Good documentation is vital for scaling engineering teams, enabling them to streamline the onboarding process, boost code quality metrics, and build & maintain high-quality software more efficiently.
Swimm is a tool designed to improve the documentation and onboarding processes for software development teams, making it easier for developers to understand, collaborate and maintain complex codebases.
With gitStream x Swimm, users can automatically approve PRs that consist of changes to Swimm files only.
This way, if a developer decides to modify a document (and nothing else), they can go ahead and merge the PR without having to wait.
Want this guide sent directly to your inbox? Click here and enter your email!
The Future of Workflow Automation
The way we see it, workflow automation has the potential to eliminate every single manual task that engineers hate, from testing and documentation to compliance and feature flags.
gitStream’s programmable workflow automation has already saved developers thousands of hours, with the average repo seeing a 61% decrease in Cycle Time.
Even now, dev teams can leverage gitStream’s control plane UI that visualizes which gitStream automations have been deployed across their repos or the organization as a whole.
With standardization and repeatability built into your development workflows, growing teams can optimize their code quality metrics, without having to compromise speed.
gitStream marks a shift in the way developers will work for years to come. We’re on our way to a world where developer toil is a thing of the past, and engineers can spend their days innovating.
Setting up gitStream takes less than 3 minutes. Set up your first rule today.
To learn more about Continuous Merge and how it can be leveraged to optimize every leg of your SDLC, check out our other CM Guides:
