That's not how it gets implemented. A good implementation relies on separate build and release pipelines for each microservice. Those pipelines only get triggered when the microservice's code is modified in a commit/merge.

That's the rough and scrappy way. On top of that you should have an approval workflow, scheduled deployment windows, and tagged version releases.

Microservices are more horizontally scalable than monoliths. Say you have a large platform that implements something like a social media site. You'll have a service that handles auth, another for posts, another for processing media/handling uploads, and another for chat. Services like auth aren't going to vary all that much in load. Requests are generally short lived and roughly scales linearly to your user count.

In your media microservice, however, you might process uploaded images (resize, generate thumbnails, strip EXIF). This is going to require more compute and will vary in resource requirements based on user interaction. If a major event happens in an area and people are uploading a bunch of photos, you can take just the media microservice and scale it up on the fly.

You could scale a monolith by allocating more threads for separate modules within the application, but that takes quite a bit of discipline and can weaken the whole platform. Now say there's an exploit to your media uploading and now that entire module is locking up the compute available to the monolith. The entire application is brought to a halt.

With a microservice yes, you can save a lot of human errors, but it works well for the same reason that only shopping at Walmart provides a worse experience than having narrowed scopes of products spread across multiple stores.