DEV Community

Cover image for How and when do you decide to update your app's dependencies?
Tim Downey
Tim Downey

Posted on

How and when do you decide to update your app's dependencies?

Cover Photo Credit: Francisco Jacquier on Unsplash

Whether you have Ruby gems, npm packages, or JARs from a Maven repository, all but the simplest of projects have external dependencies. Over time these dependencies can get stale, outdated, and even insecure.

On what cadence do you update your project's dependencies? Monthly? Weekly? Only as needed for new functionality or security updates?

How do you vet your dependency upgrades to ensure they do not break things or that they are not malicious? (see the recent strong_password gem hijacking as a cautionary tale)


My Approach

On the Ruby project I spend most of my time working on, Cloud Foundry's Cloud Controller, as well as some for some of my personal projects I do the following.

Rely on External Tools for Alerts and PRs

I've found services like Snyk and Github's own security alerts to be invaluable for keeping gems up to date from a security perspective. These tools constantly monitor the latest CVEs and cross-reference them with the versions of dependencies your project is relying on. When there are issues they alert you and can even submit automated pull requests to bump the dependencies.

Apart from security alerts, I've also found Dependabot to be helpful. It automatically submits pull requests for dependency updates in general and tries its best to include the relevant changelog entries.

Rely on Continuous Integration to Catch Regressions

Github Pull Request Travis CI and Code Climate integration

The nice thing about these services that submit pull requests is that you can hook up CI systems (e.g. Circle CI or Travis CI) to run on all PRs. You can configure these to run your test suites and give some initial feedback on the impact of the update.

Concourse CI pipelines

With sophisticated enough automation, like my team's Concourse CI pipelines you can even do things like auto-bump certain dependencies (we auto-bump our Golang version for example) and rely on the continuous builds and deployments to our integration environments.

Manually Read CHANGELOG and Browse Recent Commits

Of course for major version bumps (or minor for dependencies that have bitten me in the past) I like to manually read through the project's CHANGELOG or browse through the project's new commits. This can be tedious and time consuming, but it alerts me to any breaking changes and helps give me some peace of mind when upgrading.

That's the gist of my (kinda Ruby-centric) approach to dependency management. What do you do?

I'm particularly interested in learning more about what folks do in other language ecosystems and reading your upgrade philosophies! 😊

Top comments (1)

Collapse
 
cescquintero profile image
Francisco Quintero 🇨🇴

In the project I'm working on, we use dependabot. It's really cool because, as you said, it creates PRs with lots of information to review and merge at will or review the branch locally.

For development or testing only dependencies, most of the time I just merge, for production ones I try to review them locally whenever they're critical to the app's health.