Managing Dependabot Updates

TL;DR: Consider grouping your dependabot updates and/or changing the schedule to weekly (or longer) — I have personally seen a greater focus in the reviewing of the changes, actually merging them timely, and a reduction in overall context switching.

Dependency Management, “voxel art”

One of the more commonly accepted pieces of generic knowledge is “context switching costs the most time”. I’ve experienced this myself working in Catawiki with dependabot, and have also found some alternative strategies through some open source projects that I think may help.

Before the details, here is some context on our current deployment process:

• When a PR is merged (dependabot inclusive), it creates a build and deployment for production (we use Google Cloud Build)
• Builds for our microservices are not queued — they all execute straight — and new builds do not cancel already running builds. This all means we can get build/deployment races.

ℹ️ For brevity, this document will refer to Ruby dependabot updates, however, the same principle applies to npm packages/GitHub action updates/docker updates, etc. ℹ️

In general, our dependabot setups for most repositories are defined as follows:

version: 2

updates:
  - package-ecosystem: bundler
    directory: /
    schedule:
      interval: daily
      time: '09:00'
      timezone: Europe/Amsterdam

A Proposal

The following change(s) I think have great potential to help with context focus when it comes to dependabot PRs:

version: 2

updates:
  - package-ecosystem: bundler
    directory: /
    schedule:
      interval: weekly
      day: 'monday'
      time: '09:00'
      timezone: Europe/Amsterdam
    groups:
      bundler:
        patterns:
          - '*'
        exclude-patterns:
          - 'rails'
          - 'rack'
          - 'grape'
          - 'haml'

The changes are as follows:

• Grouping of dependencies together (With an extra exclusion for some updates that might need more attention).
• Weekly check instead of Daily.

The changes and motivations of the above are explained in the following sections

Grouping of dependency updates — Less is more

TL;DR: Removing the rinse, repeat step of atomic changes, and focusing on a single release update meant I was looking deeper into the changes of dependencies, and got more certainty about what was being changed and how it impacted my code.

Grouping of dependency updates is a relatively new feature in dependabot. I’ve personally seen the powers of this one feature in an open-source project.

At first glance, the idea of “bundling together updates” goes directly against the idea of small atomic changes. However, the behaviour that these small and repetitive atomic changes cause are less ideal.

Here is a small comparison of the rough changes in my process of managing dependabot PRs of the previous atomic style merges vs. the grouped merges.

Individual Merges (e.g. old dependabot, small atomic changes)

1. Read the changelog.
2. If it looks scary, build a tagged release and do a small smoke test.
3. Release to production.
4. Rinse, repeat.
5. Eventually getting to a point of not being able to “find enough time” to follow through with the changes atomically, since each build would take 15 minutes, and in the interim, I would try and context switch back to work, and fail.

Grouped Merges (e.g. using the new dependabot groups)

1. Reading the changelogs en masse (and in a lot of cases even looking at the git commits for more info).
2. Making the suggested changes that some dependencies recommend because of the greater focus on changelogs.
3. Building a tag, and doing a smoke test to make sure nothing died.
4. Release to production.

The key changes was that I was spending less time waiting and releasing builds, and more time focusing on the changes themselves. This gave me confidence as to what the effects of those changes may have.

Q: But what if my grouped release breaks something, how will I know which dependency was the culprit?

Great question, the common one that comes up too. In short, our debugging and logging these days should generally always lead us to the culprit. This is an easy scapegoat answer, however, the reality is that the time spent rolling back, debugging, and identifying the culprit is still shorter than the repeated context switch of releasing individual atomic changes.

⚠️ I am not advocating against small atomic commits in general. I believe those are still the correct ways to handle changes in general. ⚠️

However, with regards to dependency updates, I believe the library creators have a greater focus on not breaking their libraries (and/or documenting such things), and that trade-off compared to small atomic commits is justified.

As a final note on the grouping topic, it’s possible to declare multiple groups and exclude whatever gems you may deem important enough to have extra attention in their own right (e.g. rails, grape, etc). Additional options for groups can be found in the GitHub Docs, however, I would always encourage not making this too complex.

Changing the schedule — Weekly (or monthly) instead of Daily

The first important note is that security updates should not be affected by the interval setting 🤞.

The GitHub Docs are sparse as to what the interval setting does to the security updates. However from the docs:

Updates can be triggered based on changes to your dependabot.yml file, or Dependabot security updates

This would lead me to believe that security updates are not affected by the interval setting.

As for changing the schedule, the main arguments for shifting to a weekly/monthly are as follows:

• Context Switching — Daily bumps small interruptions vs. context focus on a less regular basis.
• Planning — By grouping the dependencies, there is a clearer and more fixed time as to when they would arrive. Over time, a general feeling for how long these merges take can be built up, whereas many small requests are much harder to track.
• Role Rotation — From experience, it’s more common in teams to have someone care more about the dependency merges than others. Some teams have duty rosters where this can be picked up, however, even then these tasks are often “Low priority”. By grouping and scheduling, an easier-to-manage fixed rotation can be put in place, and 🤞 more accountability.

As for weekly/monthly, that all depends on the team and what is being developed. The longer the gap between dependency updates, the higher the chance that the dependabot changes end up taking a significant time.

As a personal recommendation:

• Start with weekly dependabot updates instead of daily.
• If the project doesn’t have many dependency updates and/or the dependencies are stable (seen over time with updates), then think about moving to Monthly.
• If the project is in maintenance mode, seriously consider the idea of monthly dependabot merges.

Summary

Keeping an application with many dependencies up to date can be a struggle. Customizing the product (dependabot) can go a long way to helping with the process of managing these changes. With [better] configured products and cleaner processes, we can expect the load on the people to be less. The end goal is to be able to manage this process more effectively.

In the context of this blog post, we can configure dependabot with dependency groups, and schedules. With these changes, we can adjust our processes to manage these dependencies by rotating the responsibility of these changes. The end goal, is to reduce context switching and to improve the quality of the dependabot update process.