Which git metrics should I be looking at?
Engineering Metrics
Oct 19, 2023
In the intricate world of software engineering, the ability to measure and analyze performance is paramount. Git metrics, which provide insights into the development process, have emerged as invaluable tools for engineering leaders. But with a plethora of metrics available, which ones truly matter? Let's delve into the essential git metrics that can offer a comprehensive view of your engineering team's performance.
Cycle Time: The Heartbeat of Development
Cycle time, often considered the heartbeat of the development process, measures the time taken from the initiation of a task to its completion. It's further broken down into:
Coding Time: The duration spent writing the initial code.
Pickup Time: The time taken from when coding ends to when the review starts.
Review Time: The time taken for the code review process.
Deploy Time: The duration from the end of the review to deployment.
By analyzing these metrics, engineering leaders can gain insights into bottlenecks, inefficiencies, and areas of optimization in the software development lifecycle.
Number of Reviews and Review Depth: Quality Over Quantity
While the number of code reviews can provide a snapshot of team activity, it's the depth of these reviews that truly matters. A thorough review ensures code quality, minimizes downtime, and reduces the chances of post-deployment issues. By measuring review depth, stakeholders can ensure that pull requests are not just skimmed over but are meticulously examined.
New Work vs. Refactor: Balancing Innovation and Improvement
In the ever-evolving domain of software engineering, there's a constant tug-of-war between developing new features and refining existing ones. Metrics that differentiate between new work and refactor can help engineering leaders strike a balance. While new features can drive business goals and customer satisfaction, refactoring ensures the codebase remains robust and maintainable.
PR Size
The size of pull requests (# lines added + # lines deleted) can be a telling metric. Large PRs, while they might seem impressive, can be daunting to review and more prone to errors. On the other hand, smaller PRs are easier to manage, review, and integrate. By monitoring PR size, engineering teams can encourage more manageable and efficient code contributions.
PRs Merged Without Reviews: A Red Flag
Pull requests that bypass the review process and get merged can be a significant cause for concern. Such PRs can introduce errors, security vulnerabilities, and other issues. By keeping an eye on PRs that skip the review process, engineering leaders can ensure that the codebase maintains its integrity.
The Power of BuildPulse in Harnessing Git Metrics
BuildPulse Engineering Metrics stands out as a game-changer for engineering teams aiming to harness the full potential of git metrics. With its comprehensive reporting and developer copilot feature, BuildPulse ensures that pull requests, both new and stale, are promptly addressed. The platform's automation capabilities further streamline the review process, ensuring that the engineering team's workflow remains smooth and efficient.
In Conclusion
In the digital age, where software development is both an art and a science, git metrics offer engineering teams a compass to navigate the complex landscape. From cycle times that provide a pulse of the development process to metrics that ensure code quality, these measures are indispensable.
However, it's not just about collecting data; it's about making informed decisions. By leveraging platforms like BuildPulse, engineering leaders can transform raw metrics into actionable insights, driving continuous improvement, and ensuring that their engineering organization remains at the forefront of innovation.
FAQ
What is the difference between a flaky test and a false positive?
A false positive is a test failure in your test suite due to an actual error in the code being executed, or a mismatch in what the test expects from the code.
A flaky test is when you have conflicting test results for the same code. For example, while running tests if you see that a test fails and passes, but the code hasn’t changed, then it’s a flaky test. There’s many causes of flakiness.
What is an example of a flaky test?
An example can be seen in growing test suites - when pull request builds fail for changes you haven’t made. Put differently, when you see a test pass and fail without any code change. These failed tests are flaky tests.
What are common causes of flakiness?
Broken assumptions in test automation and development process can introduce flaky tests - for example, if test data is shared between different tests whether asynchronous, high concurrency, or sequential, the results of one test can affect another.
Poorly written test code can also be a factor. Improper polling, race conditions, improper event dependency handling, shared test data, or timeout handling for network requests or page loads. Any of these can lead to flaky test failures and test flakiness.
End-to-end tests that rely on internal API uptime can cause test flakiness and test failures.
What's the impact of flaky tests?
Flaky tests can wreck havoc on the development process - from wasted developer time from test retries, to creating bugs and product instability and missed releases, time-consuming flaky tests can grind your development process to a halt.
What is the best way to resolve or fix flaky tests?
Devops, software engineering, and software development teams will often need to compare code changes, logs, and other context across test environments from before the test instability started, and after - adding retries or reruns can also help with debugging. Test detection and test execution tooling can help automate this process as well.
BuildPulse enables you to find, assess impact metrics, quarantine, and fix flaky tests.
What are some strategies for preventing flaky tests?
Paying attention and prioritizing flaky tests as they come up can be a good way to prevent them from becoming an issue. This is where a testing culture is important - if a flaky test case is spotted by an engineer, it should be logged right away. This, however, takes a certain level of hygiene - BuildPulse can provide monitoring so flaky tests are caught right away.
What type of tests have flaky tests?
Flaky tests can be seen across the testing process - unit tests, integration tests, end-to-end tests, UI tests, acceptance tests.
What if I don't have that many flaky tests?
Flaky tests can be stealthy - often ignored by engineers and test runs are retried, they build up until they can’t be ignored anymore. These automated tests slow down developer productivity, impact functionality, and reduce confidence in test results and test suites. Better to get ahead while it’s easy and invest in test management.
It’s also important to prevent regressions to catch flakiness early while it’s manageable.
What languages and continuous integration providers does BuildPulse work with?
BuildPulse integrates with all continuous integration providers (including GitHub Actions, BitBucket Pipelines, and more), test frameworks, and workflows.
Combat non-determinism, drive test confidence, and provide the best experience you can to your developers!
How long does implementation/integration with BuildPulse take?
Implementation/integration takes 5 minutes!