Dependency updates
Last modified on Mon 17 Jul 2023

If it hurts, do it more often

In our day-to-day work, we'll probably face a challenge or a problem that will be tedious to solve on our own. That's where dependencies come into the equation. Even though they solve our problem at hand, they create a new, subtle one, future maintenance. Even though we didn't develop those dependencies, it becomes our responsibility to maintain them and ensure our product works in accordance.


It is our responsibility as engineers to watch out for new updates, improvements, changes, and bug fixes. In most cases, our clients or PMs don't know which exact plugin, database, or external libraries we are using so update initiative if needed, should come from us. We should check for updates regularly, otherwise, we can end up in a state where our product malfunctions, gets hard to maintain, or even worse impossible to build.

Updating dependencies should be a regular part of our job. According to Martin Fowler frequency reduces the difficulty, which is the main principle of the Continuous Integration practice:

How often?

Depending on the technology you are using, the project you are working on, or the team you are in there will be various approaches to how dependency updates will be tracked. If there is a possibility, some teams will use automated tools like Dependabot, Snyk, or any other similar tool. Other teams, due to technical limitations, will have to fall back to some manual tracking, either through Productive, Jira, or some project status sheets.

But the update cadence shouldn't differ so much, regardless of how updates are tracked or done. Checks and updates for dependencies should happen regularly, at least once a month. If, for any reason, a dependency update is not possible for a longer period, talk to your LEs or TLs and they will try to help you organize the time/project/client so that the problem gets resolved.

Common practice

Before updating any dependency, check the release notes and explore possible changes - through PRs, issues, or code changes if the library is open-sourced. It's hard to define an extensive process that will cover all possible edge cases for this part, but take into consideration a few things before updating:

If you have the slightest doubt or you are not sure what to do, **please talk with LEs, TLs, or someone more senior.