DEV Community

Ben Halpern
Ben Halpern

Posted on

How consistently does your organization update dependencies?

When the software you use releases a new version, how does your organization going about upgrading— Whether it's your core framework or smaller dependencies?

How long do you typically go before you get on the latest versions?

Top comments (21)

Collapse
 
idoshamun profile image
Ido Shamun

I've turned on dependabot on my repos and it does it for me. The only thing I need to do is approve the PR. You should try it out given the fact that Forem is an open source

Collapse
 
vaibhavkhulbe profile image
Vaibhav Khulbe

Yes! That bot is really useful! Also, if you have some heavy image assets on a project you can use ImgBot. 💯

Collapse
 
corentinbettiol profile image
Corentin Bettiol

You should use git-lfs (large file storage) for assets and other large files. Here's the github's git-lfs website (and here for gitlab's git-lfs).

Collapse
 
cchana profile image
Charanjit Chana

My previous job... never? Pace of development, size of the codebase and because of where my team was in the chain meant it rarely (ok, ok, never) happened. Not for the want of trying, but other things like code coverage, performance or bug fixes always trumped upgrading dependencies.

We were also insulated because we were so far downstream from where the infrastructure was defined and where decisions were made. That had it's own challenges but for this specific topic it was probably something we thought about very little.

For other projects I've worked on, I've been lucky that migrations were very easy. I'm talking < 15 minutes to have it done so it's been a no brainer to get it done. The caveat for that is I'm thinking back to over a decade ago and the projects were nowhere near as complicated as the ones I've worked on since.

Collapse
 
derekcrosson profile image
Derek Crosson

We use dependabot to create the PRs and then manually review and merge every few days/every week. Critical updates get deployed sooner.

Framework updates depends on capacity and what out maintenance stream looks like, security issues usually take priority

Collapse
 
vlasterx profile image
Vladimir Jovanović • Edited

For the part of the project that I'm working on - every day. I've made it my morning routine: I make coffee, sit at the computer and then check for updates for 97 NPM packages in our package.json.

  • Patch versions are updated without additional checks
  • Minor versions are run through the testing framework and build process
  • For major versions, I always check the changelog and breaking changes on Github. These are not resolved routinely, so I create an issue and resolve it as soon as time permits.

I check and update package.json with a very convenient script npm-check-updates.
So far, this approach worked great, since we never had to worry about out of date dependencies.

When you do this regularly, there is no headache afterwards ;)

Collapse
 
kedarjoshi profile image
Kedar Joshi

In my organization, the answer varies from project to project. Some of the projects haven't had a dependency update since last 2 years and they are still in active development.

Some projects update their dependencies on hourly basis i.e. as soon as it's released. This is possible because these projects have a bleeding-edge branch which runs CI jobs with latest versions of all dependencies.

Collapse
 
wrldwzrd89 profile image
Eric Ahnell

It depends on lots of factors: user base, potential for disruption, etc. but in general, I am aggressive about upgrading, preferring to move sooner than later.

Collapse
 
cchana profile image
Charanjit Chana

Always the intention, but in the past few years it's never been a reality for me! Looking to adopt this approach as soon as I can with the new teams I'm working with though!

Collapse
 
lexlohr profile image
Alex Lohr

We have a renovate bot to do that for us... unless something breaks, like for example enzyme compatibility with react 17 (we still have some old components using it for testing, but we'll be removing both them and enzyme at some point, but currently it's a blocker). So the longest should be probably 1-2 months.

Collapse
 
gklijs profile image
Gerard Klijs

Most things are Spring Boot and use a regurly updated internal parent. We try to keep soms additional libraries up to date.
We have some vulnerability checks that might lead to updates for infra parts. Then there are a few infra depencies like terraform we are hassistent to update because they often give problems.

Collapse
 
wolfhoundjesse profile image
Jesse M. Holmes

I don't understand the question. 😂

Collapse
 
kspeakman profile image
Kasey Speakman

For active projects, we tend to evaluate package updates at the beginning of a new sprint.

For inactive projects, very rarely. :(

Collapse
 
corentinbettiol profile image
Corentin Bettiol

We have some old projects in Django 1.4.

But it's getting better and better, we update our most recent project monthly (django 2.2 & django 3).

Collapse
 
alanmbarr profile image
Alan Barr

Usually never unless someone is passionate about it. I watch this video and I lament that reaching this nirvana is unlikely. youtube.com/watch?v=j6ow-UemzBc

Collapse
 
alphavader profile image
KB

Update depends on the features. I tend to update everything frequently. For bigger teams this is a bigger task with a certain sprintgoal.. Coming with the update.. Testing.. And deploying..

Collapse
 
bschalme profile image
Brian Schalme

At my most recent client engagement, I would check every couple weeks. As the Lead Developer, I would have the development team update the dependencies the next time the code was opened up for change.

Collapse
 
nawhitter profile image
Natasha Whitter

We don't have a process, but I tend to do most of the dependencies/framework updates (I dislike being too many versions down from the newest build). Usually, I do this every couple of months.