Microservices should not be mass deployed together but be managed separately. That vastly simplifies the combinatorial explosion of versions you need the worry about: the currently live ones.
The rest is just applying SOLID principles to your microservices and avoid having services with poor cohesiveness or tight coupling (most of the SOLID principles boil down to affecting these two metrics). Bad service design with tight coupling where deploying service A also requires redeploying B,C,and D, is basically a design problem and not a micro services problem. There's a lot of bad design in our industry. Monoliths allow you to get away with that but it's also the reason that breaking them up is a hard problem. Just because you are getting away with it does not mean it is not a problem though.
You can further mitigate integration issues by deploying using modern practices like blue green deployments where you gradually move traffic to a new versions and adapt on things like error rates and other metrics, AB testing, etc. So if it breaks, you don't end up breaking it for everyone and you can fix the problem and try deploying that in a controlled way.
Basically your goal is to keep your customers (aka. dependees) happy and make sure you don't negatively affect them (which you should be actively monitoring). Likewise if you have dependencies (to whom you are a customer) and they stop working when you deploy something new, you probably want to detect and fix that before you break all your customers. If that is a regular thing, consider having integration tests, contract tests, etc.
Staging environments are a controversial topic in this context. My view is that they don't make much sense in a properly run micro service deployment since you are not testing in a real environment with real users, real data, and lots of things happening concurrently and features interacting. And of course your customers doing real things they care about. The only realistic environment that has that in most complex micro service deployments is called production. Once you add serverless and edge computing to the mix, these things become even more true. The bigger the organization, the less feasible it becomes to have a staging environment.
Update. I forgot to add this but doing continuous deployment means small deltas that are low risk. Any bigger change can be behind a feature flag. There are a few more strategies.
Also, I'm not actually a microservices proponent for small teams. It just creates deployment and operational overhead (read go to market bottlenecks).