“If it hurts, do it more often”

That’s one of my favorite sayings. You’ve probably heard it before from Agile or DevOps contexts. It seems counterintuitive, maybe even wrong at first. It’s more natural for us to defer things that are painful or avoid them altogether. And of course, if you do something repeatedly exactly the same way, expecting different results, nothing improves.

But that’s not the point.

The point is what happens when you get forced to do something more often: You understand it better, you get better at it, you get really annoyed by it, you get motivated to simplify it and finally to automate it.

That has been the main idea behind Continuous Integration and Continuous Deployment and it comes up a lot in Agile: Testing, refactoring, planning, releasing - everything is done more frequently.

I think it’s important to point out that it’s not just an 1 hour task that gets split into doing a 10 minute task six times. It’s significantly less work than the 1 hour task. Why is that? According to Martin Fowler there are three main reasons:

  • The smaller tasks are much easier to understand, but still compose well into the bigger task.
  • You get faster feedback from smaller tasks, which is what you want.
  • You get better at tasks you practice often.

How about dependency updates?

So if this is a well understood concept from Agile, why are we not doing the same thing for keeping dependencies up-to-date?

Updating dependencies is fundamental for the security and ongoing health of your project, yet it’s usually pushed aside for more visible work. It’s very rare to find teams that have a well defined practice of keeping their app up-to-date.

Why is updating dependencies only done when someone has extra time, or only when you really need to bring in that security update and suddenly have to update a lot of packages at once?

At Depfu we believe in doing dependency updates more often, because right now they hurt. And they don’t have to:

  • Dependency updates compose well: It’s easier to update 5 packages individually than all at once: You’ll know what change caused the build to break or find the cause of performance regressions after a deploy. It’s also a lot easier to assess the risk of a single package update than running npm update and hoping for the best.

  • When updating dependencies in smaller chunks, you’ll have a lot less changes in your deploy, which means errors are easier to locate. If you believe in continuous deployment, shipping thousands of changed LOCs hidden in your dependency updates must make you angry.

And that’s what Depfu is really helping your team with: A continuous process for dependency updates.

PRs instead of emails

Depfu keeps you up-to-date by sending you super nice Github pull requests about new versions. You can assess an individual update very quickly because the PR has all the info you need: link to the changelog, list of commits and most importantly your test results.

Knowing if your tests pass with a new version is such an important piece of information. Not having to wait for your test suite to finish dramatically shortens the feedback loop.

Depfu automates the boring parts: running npm update package_name, figuring out what actually changed in the new version and waiting for your test suite to finish.

In the simple cases all you have to do is click that merge button, and you’ll get better at the more complicated cases, because you’ve been practicing!

Why don’t you see for yourself how Depfu can help you? You can try it for 3 weeks on your private repos and it’s free forever for open source: Start getting up-to-date.