Is your software up to date? Have you been applying those gem security patches? Are you keeping up to date with python version upgrades? Have you ever been surprised at just how far behind one of your packages is?
We need a metric to measure and track the age of source code dependencies. The software industry has settled on great practices like static code analysis, as well as automated testing, continuous integration, and continuous deployment. We’ve got nifty analysis tools and badges that let us know when all of our tests pass and alerts us when cyclomatic complexity is too damn high. We even have tools to notify us of security alerts in our dependencies. And the newest innovations are robots like Dependabot to actually do the upgrades for us.
All of these innovations have helped further the pace of software development. Now it’s time we had a metric to convey how current our software dependencies are. We have devised one such metric and we call it Dependency Drift.
Why Track Dependency Drift?
The primary benefit of tracking software dependency aging is to objectively report on your team’s commitment to package upgrades. Keeping up to date is hard: the pace of development can be frantic at popular and emerging dependencies. If you do nothing, your software will gradually drift out of date.
Staying current by upgrading incrementally is vastly easier than waiting years and trying to jump 4 versions ahead for that sweet new feature or critical security patch. And reporting on your progress is the first step toward tackling this challenge consistently.
The benefits of a Dependency Drift metric are numerous:
- Provides an “at a glance” health check to communicate a team’s commitment to keeping their dependencies up to date.
- Aides in the assessment of the health and recency of open source packages when searching for libraries to solve problems.
- Integrates into a continuous integration pipeline, optionally forcing updates in order for software to ship.
- That sweet green badge and bragging rights when your rating is high and your dependencies are current.
Software quality, maintainability, and security will benefit from Dependency Drift. Today, it’s difficult to get a sense for how up to date dependencies are for a project. Maybe your team is vigilant and uses cutting edge tools like Dependabot to keep dependencies current. But there is no way to know at a glance or to track progress over time.
Our goal with the Dependency Drift metric is to boil down the recency of all a project’s dependencies into a single meaningful grade. A grade of A through F will easily communicate how current a project is. The ability to incorporate Dependency Drift analysis into a continuous integration pipeline could provide alerts when drift occurs and your dependencies are getting stagnant.
Vision and Roadmap
Here’s what we envision for the future of the Dependency Drift metric idea:
- Create a numeric metric that incorporates the volume of dependencies and the recency of each of them.
- Devise a simple high level A-F grading system from that number to communicate how current a project is with it’s dependencies. We’ll call this a drift score.
- Regularly recalculate and publish for open source projects.
- Publish a command line tool to use in any continuous integration pipeline. In CI, policies can be set to fail CI if drift is too high. Your drift can be tracked and reported to help motivate the team and inform stakeholders.
- Use badges in source control README files to show drift, right alongside the projects’s Continuous Integration status.
What do you think? We are looking for community input and value your feedback. Do you agree with us that such a metric might benefit the industry? If you do, you’re in luck because we’re already working on making this vision a reality and we are calling it DriftWatch. If you have misgivings or input, you’re also in luck because we are in the very early stages of developing this concept.