Make each change small, add a few smoke tests on the paths that earn money or hold data, roll out gradually, and keep a fast rollback. With thin coverage you cannot trust a green build, so you compensate with smaller steps and observation.
Why green is not enough
A passing test run says only that the tested behavior still works. If most of your behavior is untested, a bot pull request can pass and still break production. Automation raises the volume of changes, so weak tests hurt more once a bot is on.
Steps
- Pick the five user journeys that matter most, such as sign in, pay, export and one core feature.
- Write one end to end smoke test for each. A rough test that runs is better than a perfect plan.
- Run those on every dependency pull request.
- Update in order of risk: patch updates first, then minor, then major. For packages at 0.x, treat minor bumps like majors, because the semantic versioning specification allows anything to change in major version zero.
- Merge one pull request at a time for production dependencies. Do not group when you cannot diagnose.
- Deploy to a staging environment or a small slice of traffic before everyone.
- Watch error rates and key business numbers for a day after each release.
- Keep a rollback you have tried. If a revert is a two minute action, you can move faster.
Compensating controls
| Gap | Control |
|---|---|
| Few unit tests | Smoke tests on key journeys |
| No integration tests | Staging deploy with manual check |
| No monitoring | Add error and latency alerts before you automate |
| Slow rollback | Practice a revert and write down the steps |
What not to do
Do not turn on auto-merge. It trades review for speed, and review is the only safety net you have. Do not stop updating either. Skipping updates builds debt, and large jumps later are riskier than small steps now.
Grow coverage with the work
Each time an update breaks something that tests did not catch, add a test for it. After a few months the tests will reflect what actually fails in your system, which is worth more than a coverage percentage chosen in advance.
Use scoped help
Analysis that shows which dependencies your code actually calls helps you decide where to spend scarce test effort. A package that no code path reaches is a lower testing priority than one on your payment path.
Try it yourself
Click through it at your own pace, or open it full screen. Check which flagged packages sit on a real code path. Put your scarce smoke tests there first.
Quick check
Should a team with few tests turn off the update bot?
No. Keep it on with a low pull request limit and merge carefully. Falling far behind makes later upgrades larger and riskier.
What is the minimum useful test set?
A smoke test for each critical journey, run on every dependency pull request, plus monitoring after release.
Safeguard scans manifests and lockfiles into an SBOM, uses reachability analysis to show which flagged dependencies your code actually calls, and can open fix pull requests (off by default, every category on Manual). You can try a free scan on a public repository.
Sources
Last reviewed: 19 October 2026.
