I am trying to get some input from people working on large projects with many devs involved, about how do you manage your 3rd party dependencies.
Let me be more specific:
Let’s say that in our organization we are working on several big projects, some are infrastructure projects that are consumed and used by other projects.
Naturally, all projects have 3rd party dependencies and you need to update them at some point.
What is your strategy?
The considerations are (if you have other, please do tell):
security - you don’t want to stay with old versions
same but simply to get the latest bug fixes and updates
you might break often if you keep updating every build for example
when you update your infra projects, you might break your depending projects that are using you as a dependency.
What is your strategy?
- You do something automatic like dependabot?
- Do you update each time you build and handle breakage as it occur?
- Do you have a “scheduled event” for updating libraries? if so, how often?
- You only update when something demands it (security alert, required feature, another library requires it, etc…) Something else? Thanks!
Top comments (7)
Dependabot or renovate, review once a week. If it's a breaking change that doesn't resolve a feature/bug I need, or a security issue, it gets pushed back until maybe once a month.
All PRs build a preview environment, so I can quickly see if a build is failing or if the site is broken from an update and act accordingly.
One question, the weekly review you mentioned, I assume that if everything works then there nothing to review, right? when is this review is needed? when things don't work automatically? if updates break stuff and the PR cannot be completed automatically?
thanks!
We always get PRs from dependabot.
On Monday, I just go through each to make sure the builds are good and the affected areas of the app aren't broken. Each one that is good gets merged to the staging branch.
Once the staging branch gets approved, it is tagged for release, and merged to main to deploy.
If something breaks, it'll break in the deploy preview or the staging deployment, so its just a matter of fixing it before it goes to the main branch.
I always add a note to the PR about what broke. Generally, I'll try and revisit it that day. Otherwise, I'll come back later in the week when I've got some time.
If something is a breaking change that doesn't impact us and isn't a security patch, it's just closed. Dependabot will keep reopening patches and minors on that as time goes on, so I can keep closing it until it's a valuable change.
thank you for the info, very useful stuff
thank you! I didn't hear of Renovate before. going to check this out (I might have some problem using dependabot since its not available in GitHub enterprise yet (its on the roadmap for next year)
Renovate supports enterprise I think. I see more big orgs using it instead of dependabot.
Depends if you have a good test suite with wide coverage and you feel confident with it. If so, check dependabot PRs on a regular cycle (once a week or 2 weeks or once every sprint)
Else, focus on getting that test suite