Usually have pretty good test coverage, I've tended to suggest setting aside one day a month to update all project(s) and dependencies, much like Systems Admins will often do the same (more) for system updates.
Most of the time, the updates don't require code changes, so it's maybe an hour, then tests, smoke tests, test/uat pass and release, like any other more significant frequent release ci/cd cycle. About twice a year, it may be deferred for a couple days, if there's a major library update with breaking changes. In those cases, new story(ies) go into the top of the backlog to handle it as a higher pointed change.
Not every environment will follow the above... which is how you see projects with multi-year old dependencies, sometimes 2+ major releases behind. IMO, it should be considered the same as ceremonies and planning, it's just part of the lifecycle. That it doesn't get treated as such is the issue.
Most of the time, the updates don't require code changes, so it's maybe an hour, then tests, smoke tests, test/uat pass and release, like any other more significant frequent release ci/cd cycle. About twice a year, it may be deferred for a couple days, if there's a major library update with breaking changes. In those cases, new story(ies) go into the top of the backlog to handle it as a higher pointed change.
Not every environment will follow the above... which is how you see projects with multi-year old dependencies, sometimes 2+ major releases behind. IMO, it should be considered the same as ceremonies and planning, it's just part of the lifecycle. That it doesn't get treated as such is the issue.