DEV Community: Jamie Tanna

Why I recommend Renovate over any other dependency update tools

Jamie Tanna — Fri, 12 Apr 2024 10:06:35 +0000

NOTE This post was originally posted on my blog

If you've read my blog before, or interacted with me at work or in the Open Source world, you're likely to know that I'm a huge fan of Renovate.

For those that aren't aware, Renovate is one of the big players in dependency updating tooling, commonly seen in comparisons with Dependabot or Snyk.

I've been using Renovate for the last ~5 years, alongside a mix of Dependabot and Snyk to keep me grounded. I absolutely love Renovate, and make a point of making it so I can run Renovate where possible.

I've also had the experience operating Renovate in self-hosted mode as well as used the hosted Renovate app by Mend and the Mend Enterprise SAAS, and plan to blog about the lessons learned self-hosting Renovate.

Renovate has some really key features that set it apart from the competition, and I'm sure in the time it's taken me to write this, they've shipped some new ones 😻

(Aside: I'm largely writing this blog post now, as I've recently been shouting the benefits of Renovate, and instead of writing another internal-only document at work (as I did at Deliveroo), I wanted to write it as a form of blogumentation).

Prior art

A few years back, I wrote about some tips for using Renovate to make keeping your software up-to-date easier, which I still stand by.

Since then, I've worked across a number of different ecosystems, repository sizes, and levels of comfort merging dependency updates, and have learned a few more things about effectively using Renovate - but through it, I'm still very sure of Renovate being the best tool in the ecosystem.

Configurability

Renovate is extremely configurable, with dozens of configuration options to tune your experience. But Renovate doesn't end up being "too" configurable, where you end up spending more time tweaking config than doing the changes, but configurable enough that it's very likely you can do what you need to with it.

Centralised, shareable presets

This is something that really hit me when we were rolling out Dependabot at Deliveroo, where my team owned ~30 repositories, and so for each of these repos, we needed to hand-craft a dependabot.yml, as Dependabot needs to be told which directories contain which dependencies, and how often to update them.

After we'd had about a week of usage, we started needing to tweak the configuration in a few of them to reduce the noise, which then required us to raise PRs across all the repos and get them updated.

Because Dependabot requires a bit of a snowflake configuration per repository, this wasn't easily automatable, even with great tools available to automate some of the bulk updates, which made this a rather onerous and frustrating process.

Compare this to Renovate, where there's an excellent first-class support for shareable config presets, in which you can "extend" multiple configuration(s).

This allows a team that wants to have consistency (i.e. in how often they receive updates to the AWS and Google Cloud SDKs, or which labels they want on PRs) to create a shared preset for their team that defines this. Then, each of their repositories can "extend" this configuration, as well as defining their own configuration on top of it at a repo-specific level.

This also makes it possible to provide good guardrails for your organisation, providing a good set of defaults, such as a base.json:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "postUpdateOptions": [
    "gomodTidy",
    "gomodUpdateImportPaths"
  ],
  "regexManagers": [
    {
      "fileMatch": [
        "^Makefile$"
      ],
      "matchStrings": [
        "curl .*https://raw.githubusercontent.com/golangci/golangci-lint/master/install.sh | sh -s -- .* (?<currentValue>.*?)\\n"
      ],
      "depNameTemplate": "github.com/golangci/golangci-lint",
      "datasourceTemplate": "go"
    }
  ]
}

This then allows defining a somewhat opinionated good starting point for teams with a default.json:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": [
    "local>your-org-here/renovate-config:base",
    "config:best-practices"
  ]
}

Then, teams only need to set the following in their repos' renovate.json, and they'll have the benefits of onboarding with a lot of the hard work done with starting:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": [
    "local>your-org-here/renovate-config"
  ]
}

And that's it 👏

Good defaults

Linking back to the comment about having to hand-craft dependabot.ymls, the great thing about Renovate is that there's some great defaults, and that it can autodetect the ecosystems your repo uses, and appropriately raises PRs.

This ease of onboarding is truly excellent, and you can even have an onboarding PR raised to your repos to make it even simpler.

For instance, at Deliveroo, we made it so there was a default set of configuration for all repos to give us an easy means to update Docker images, but then if teams wanted to manage everything, they could add a renovate.json, and it'd be more fully featured.

Additionally, Renovate comes with some great inbuilt configuration in the form of presets, including a "best practices" guide and associated preset, which makes it easier to keep on top of community best practices, without needing to bikeshed about what you think is best.

If you find that config:best-practices is a little too much, there's config:recommended as a starting point, and you can always downgrade or exclude rules you'd prefer not to follow. Or if you really want to control things config:base is the minimum you should pull in.

Grouping

As suggested above, it's possible to tune how different packages get updated, where you can group multiple updates into a single PR.

For instance, let's say that you use 9 different AWS services in your application, and instead of receiving 9 PRs every time there are updates across the SDKs, you want a single one. In this case, you could craft the following Renovate configuration:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "packageRules": [
    {
      "groupName": "aws-sdk-go",
      "matchPackagePatterns": [
        "^github.com/aws/aws-sdk-go-v2"
      ]
    }
  ]
}

What's great about this is that you can also bundle things like all patch updates into a single PR:

{
  "packageRules": [
    {
      "matchPackagePatterns": [
        "*"
      ],
      "matchUpdateTypes": [
        "patch"
      ],
      "groupName": "all patch dependencies",
      "groupSlug": "all-patch"
    }
  ]
}

This is something that's recently been added to Dependabot, which is great, cause Renovate's had it for years 😝

Use for one-off bumps

Because Renovate is an Open Source tool you can run on the command-line, it means you can also get the ability to use Renovate for one-off executions, for instance to get everyone in your organisation to a minimum version of a given dependency, or just to do an infrequently performed set of updates.

Supports more than other tools

Something I always refer back to is the fact that Renovate has a tonne of supported package managers, package ecosystems and versioning tools.

Renovate's bot comparison guide docs has a good example which links out to the differences between:

As Dependabot is more focussed on being used on GitHub's platforms (citation needed?) support for things like CircleCI, GitLab CI or other competitors' tooling doesn't seem to be available.

Adding support for additional ecosystems

One of the things you'll be used to having from your dependency update tool of choice is your standard package manager support, where it'll update a go.mod or a pom.xml in your repositories.

But one thing that's quite important to understand is that there are many more dependencies in your project than those installed in your package manager. Something I find great about Renovate is that, as well as managing Dockerfiles, build.gradles, .gitlab-ci.yml, etc, it will also manage things your .ruby-version or configuration for the ASDF version manager.

But what about some of the non-standard, or organisation-specific means for tracking versions?

For instance, installing the golangci-lint linting tool recommends using curl | sh:

$(GOBIN)/golangci-lint:
 curl -sSfL https://raw.githubusercontent.com/golangci/golangci-lint/master/install.sh | sh -s -- -b $(GOBIN) v1.57.2

And it's common for Dockerfiles to have a definition of the version of dependencies:

ARG MONGODB_VERSION=6.0.4

Or what if you have a custom deployment configuration like:

# this is an (imaginary) company specific deployment configuration file
application:
 lb:
 image: uk-tooling/load-balancer@v3.0.0

It's very unlikely that you have these supported by other tools out-of-the-box, and Renovate is the same.

But Renovate does give you the ability to manage these versions yourself.

Using Renovate's custom managers we can craft a configuration file such as:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "regexManagers": [
    {
      "fileMatch": [
        "^Makefile$"
      ],
      "matchStrings": [
        "curl .*https://raw.githubusercontent.com/golangci/golangci-lint/master/install.sh | sh -s -- .* (?<currentValue>.*?)\\n"
      ],
      "depNameTemplate": "github.com/golangci/golangci-lint",
      "datasourceTemplate": "go"
    }
  ]
}

And this will allow us to manage the golangci-lint installation.

Ideally, this sort of configuration may make it upstream so Renovate can do it out-of-the-box, but as we can see from the above example, there may be things that are organisation- or repo-specific, and so having it upstream'd doesn't make sense.

Because you can do more with it

And you can do even more with it - I've mentioned you can use it for one-off updates on the command-line, but for instance I've also written a tool renovate-graph which takes the detected dependency data from Renovate and gives you a JSON blob you can consume.

This underpins a large swathe of the power behind dependency-management-data and can be used for other means, such as converting Renovate data exports to a Software Bill of Materials (SBOM).

Dependency Dashboard

One thing I love about Renovate is that you can enable the Dependency Dashboard, which gives you an overview of the detected dependencies, open PRs, as well s anything that may be waiting, or has failed to update.

This is a hugely useful insight into the at-a-glance how far behind are we on updates, giving a view of whether you maybe want to spend a bit more time focussing on updates, or looking at ways to cut through the noise.

When you merge a PR into your default branch, Renovate will rebase open PRs, so they're easier to review, and are guaranteed to run against the latest changes. However, if you're not getting to your updates as often as changes are going in, you may have a tonne of PRs constantly building, which is a waste of energy and CI minutes.

Instead, you can use the Dependency Dashboard for its ability to i.e. require major bumps be gated behind a manual approval, as it's likely you'll need some human interaction for that PR, and can then only raise it when you're actually ready to deal with it.

Open Source

A very important factor to me is that Renovate is Open Source, and open to community contributions.

Although it's probably best to be split into another article, I love the AGPL3, and it's a great way of making sure that anyone hosting Renovate as a platform makes sure that their users get the access to the source code.

Alternatively, Snyk is proprietary, and Dependabot is source available (or at a stretch "open source" not "Open Source") with a license that doesn't even appear on the SPDX license list.

Renovate is also brilliantly set up as a community project, where they're shipping hundreds of PRs a month, alongside managing the community really well. I've seen a few things change in the last few years I've been more actively contributing, and it's a really well run project and an indication of something I'd love to be able to replicate at some point!

It also helps that Mend, the company behind Renovate, invests a fair bit of time and money into development of the project, as well as their commercial offerings on top of it, which continue to make the project sustainable and remain Free and Open.

Great documentation

Following on from the excellent community and maintainer contributions alike, there's also some really excellent work on a technical writing and documentation point of view, which makes a lot of tasks straightforward to solve.

If there's something a little more complex or custom than the docs can offer, it's usually something that can be answered by the community in a GitHub Discussion, and likely could turn into a docs improvement, if necessary.

There's even a great comparison table between Renovate and other dependency update bots, as well as tips on how best to update your projects.

I've recently discovered a few pages and features that I wasn't aware, just by going through the docs.

Overall

In summary, there's just so much that makes Renovate a greater choice than any of the alternatives, and I'm sure I could talk about more things that make it great.

Whether you self-host it for maximum control (such as being able to access internal artifact registries), or run the hosted app for ease of operations, or just run it from the command-line once in a while, it can be hugely useful to your experience as an engineer.

I hope you'll check it out!

Lessons learned since posting my salary history publicly

Jamie Tanna — Thu, 19 Jan 2023 11:45:57 +0000

This post originally appeared on my personal website.

Just over a year ago, I did something quite "out there", even for me, and I posted my salary history publicly. This was accompanied by a blog post to explain why I was doing it, and it's certainly been popular.

When I first posted it, I made a note to myself to come back in a year, and see whether anything had changed, as well as to look back on some of the events that happened immediately after my posting, as it certainly made life interesting in the month or so following the post. I wrote up a lightning talk I did the month after, but this should give a bit more insight on further reflection.

The usual caveats apply of the fact that this is a personal post, detailing personal experiences, and doesn't represent the views of any employers. I have also made efforts to remove a number of key details, which would tell a more realistic story, but are probably best told in person, rather than on the Internet.

How many people have seen it?*

Probably one of the key things you, dear reader, want to know is how many people have seen the page?

I love the dopamine rush of watching my analytics climb up after posting a new post, or trying to work out where referrers are coming from when I see a sudden spike in hits, and I will always have my analytics open in a window on my desktop, so I can see what's going on at the moment.

So how many people have seen this? My first caveat for these numbers is that privacy-protecting browsers and extensions often block it (which is absolutely fine, by the way!) so these numbers are definitely not as many as it's actually gotten, it's just based on how many people don't block my analytics.

Page	Number of views	% of overall site views (between 2021-09-09 and 2022-09-21)
Salary page	11818	4.1
Salary blog post	3035	1.1

One of the most interesting things is how many direct hits I get on the page - it's often not discovered on my site's header, or via the feed, but it's by someone either arriving through a privacy-preserving referrer, or they're here by a direct link someone else has sent them. Probably the most organic way of building traffic I've ever had, including being featured on a podcast, and in several newsletters!

I got a lot of (private) thanks

In the days after posting it, I received loads of private messages from folks, a good number from underrepresented backgrounds, to say thank you for posting it, and that it's really been helpful for them. I also know of at least 3 people who've used it to get a considerably better paying job, which is really amazing.

I'd love to hear if it's been great for you, too.

It's got more people sharing theirs

Something really awesome is that since I posted my blog post, I've had a number of other people in the tech community sharing their own salaries. I know of at least 5 people who've done it off the back of my post, which to be honest is really quite cool. It's nice to have been able to nudge a bit of change.

I'm capturing them by tagging them with my salary tag (although I will caveat that it is included with a lot of other posts, sorry it's not as discoverable!) and hope to have pages of these in the future!

Didn't check legality

In my usual way of living my life, I didn't quite consider the consequences of what I was doing, I'd just got it in my head that I wanted to do it, so I did it.

It wasn't until it was being actively discussed on the Tech Nottingham Slack that I realised it could have been illegal to talk about 😅 Fortunately, it was all OK - and I double checked in my contract - but not ideal to be finding that out after it's already been read by quite a few folks.

People are more comfortable sharing privately than publicly

Something I completely appreciate, and massively applaud, is that people are still talking salary, just not publicly. Talking about topics like this is hard even with friends, let alone putting it out for the whole world to see.

I know a few people who've said that they're worried it comes off as if they're "showing off", or that they'll be devalued as a person because their salary is lower than someone else's.

It's absolutely a difficult one to deal with, and I guess if you can get yourself over that, it's great but if not, that's also OK. But it's still awesome that a lot of people are talking about salaries with friends, and hopefully it's helping more people bridge the topic.

Probably(?) not been bad for me

So far, I don't think I've been negatively affected by the move. It didn't seem to block me moving jobs, and I've not had anything explicitly saying it's bad, but it may have been causing people to look down on me behind-the-scenes, and I wouldn't know.

I asked companies about whether they were comfortable with me sharing salary details when applying - if they'd not already done their background research on me - and they were happy with it.

I would say that one thing I as an employee bring to the table is a level of transparency, both internally and externally, and it's nice to be in companies that value this, whether it's my salary or talking about what I'm working on.

Wider impact

Unfortunately I can't take the credit for California deciding to require salary ranges on job applications, but I can definitely take some wins closer to home.

I know that the Nottingham job market was affected by my post, as suddenly a lot of recruiters knew exactly what salary and progression looked like elsewhere, as well as people looking at moving elsewhere having more of an idea about what that would be like.

There's definitely a company in Nottingham that started to discuss their salary ranges being put publicly on job posts after my post, but I've not had a chance to check if it was done.

Great for current employers

I would also say that generally his has been positive for my employers.

When I worked in the government, our salary ranges are public and transparent, and it's really great to make things fair for candidates and employees alike. Putting my individual salary on top of that didn't help too much, because people could guess where in the salary band I'd be landing, but in a private company, it makes a lot more of a difference.

At Deliveroo, we compensate exceptionally well in terms of salary, so having that extremely public, as well as the submitted salary information on sites like Glassdoor, has been - from what I've been told - positive for the company, and convincing more folks to come work for us. It also helps that we've got some great tech, great problems, and you can spend most of your days delivering value to customers 🤓

There are things like levels.fyi, Glassdoor and Google Sheet of (mostly US-based) salaries going around, but it's nice to have other options, to see what you could get compensation wise.

Does it make negotiation harder?

One concern people have is that if they've got their current salary, they believe that negotiating for a raise/new job is harder.

I'll definitely defer to someone who's well versed in negotiation - there are some great workshops out there! - but I'll say for me, I'm privileged and comfortable being a bit more entitled in the world.

I did find it difficult at first going into a couple of job applications, where they requested a range that you'd be interested in getting, but I increased the numbers a good chunk from what I was currently getting, and that worked out well 😁

But remember that just because they know what you're currently being paid, doesn't make it like they have any more power over you - if, before you've even started, they want to knock your salary down as much as possible, it's unlikely to get better the longer you work there.

The "counter offer"

One thing that I found out in my exit interview at Capital One is that the mistake I made while posting this was to call something a "counter offer" from Capital One. It was noted that this wasn't a counter offer, it was a "your salary is being updated anyway for competitiveness", but I'd misinterpreted the exact wording, as it sounded like a counter at the time.

Unfortunately by the time I'd been told, the damage had been done, and I'd caused some awkward conversations internally about counter offers. I've now removed the reference to this "counter offer", but thought it should be talked about.

Take it with a pinch of salt

As often comes up in conversations about salary - take the numbers with a pinch of salt. I've had a number of US-based folks call me woefully underpaid at £90k fully remote in Nottingham, whereas looking at that compared to folks who are also Senior Engineers at Nottingham-based companies, it ain't me being underpaid 🤑

Also remember that the salary doesn't necessarily take into account things like workload, personal development time, and benefits - use it as a guiding factor, not the be-all-and-end-all!

Regrets

Hah, tricked you - I don't have any! I've found it to be a really good experience, and am really glad that I've been able to enact some change.

There's some interesting conversations on Lobsters about salary history pages that may be good as some further reading.

Here's to the rest of my career being as transparent!

Deploying a Branch to Netlify on the Command-Line

Jamie Tanna — Wed, 03 Jun 2020 20:02:15 +0000

This post originally appeared on my personal website.

I'm very excited to say that the Netlify CLI tool ( netlify/cli) now has the ability to deploy a branch on the command-line.

This has been a feature request since at least 2018 and has been greatly anticipated from the community, and I've been wanting to use it for some time when using GitLab CI pipelines.

As of netlify-cli@2.53.0, it's now possible to deploy using the -b $branchName flag:

% netlify deploy -b wibble
Deploy path:        /home/jamie/workspaces/talks/public
Configuration path: /home/jamie/workspaces/talks/netlify.toml
Deploying to draft URL...
✔ Finished hashing 286 files
✔ CDN requesting 0 files
✔ Finished uploading 0 assets
✔ Deploy is live!

Logs:              https://app.netlify.com/sites/epic-wozniak-9aa019/deploys/5ed7eaedb88cedbb42a9d341
Website Draft URL: https://wibble--epic-wozniak-9aa019.netlify.app

If everything looks good on your draft URL, deploy it to your main site URL with the --prod flag.
netlify deploy --prod

This is super exciting, and will help help folks deploying from Continuous Integration platforms, or with use cases where they don't want to use Netlify's Webhook integrations.

Generating HMAC Signatures on the Command Line with OpenSSL

Jamie Tanna — Fri, 21 Feb 2020 09:46:46 +0000

This post originally appeared on my personal website.

Proving authenticity of a message is important, even over transport methods such as HTTPS, as we may not be able to require full end-to-end encryption. One such method of producing a signature is using HMAC with a shared secret.

For instance, let us say that we want to use SHA256 as the hashing algorithm.

If using Java, we could write code similar to the below, leveraging the commons-codec project:

import org.apache.commons.codec.binary.Base64;
import org.apache.commons.codec.digest.HmacAlgorithms;
import org.apache.commons.codec.digest.HmacUtils;
// ...
String digest =
    new String(
        Base64.encodeBase64String(
            new HmacUtils(HmacAlgorithms.HMAC_SHA_256, "secret-key-here")
                .hmac("value-to-digest")));
// G73zFnFYggHRpmwuRFPgch6ctqEfyhZu33j5PQWYm+4=

However, this doesn't help when we want to script this from the command-line, and isn't as portable.

To do this we can utilise openssl:

$ echo -n "value-to-digest" | openssl dgst -sha256 -hmac "secret-key-here" -binary | openssl enc -base64 -A
// G73zFnFYggHRpmwuRFPgch6ctqEfyhZu33j5PQWYm+4=