You'd be surprised. With a microservice you still need to coordinate the release with other consumers of it.

I'm well aware of that. This type of coordination is much easier, than producing a new build in a complex corporate environment. The delivery of microservice is limited in most cases to the change in environment inventory file and integration testing. The delivery of the build requires source code management (you'll need to push the dependency change in the right branch), probably, full application SQA cycle (to make sure there's no side effects, e.g. due to transitive dependency update) and only then - deployment and integration testing.

It shouldn't be a big deal. https://en.wikipedia.org/wiki/Continuous_delivery

It shouldn't, but in practice sometimes is. It's not the pushing of bits that's hard; it's the ensuring that the library got everywhere it needed to go and that the new release of the other users of that library didn't introduce any bugs.

Imagine you have a library that implements the serialization and deserialization of something in your system (or anything else where the library implements two "halves" of some functionality). You might (or might not, depending on the change) need to push out that library to other apps to effect the fix you're working on. That new proposed library change may be in a queue behind another pending change that's in development, etc.

> it's the ensuring that the library got everywhere it needed to go and that the new release of the other users of that library didn't introduce any bugs.

And guess what, you have to do the same thing with microservices. You must ensure that all its clients are pointing to the correct version, and you must ensure that the new version didn't add any bugs in the clients.

Adaptations for new service versions will also get into the release queue, and can also get blocked by other stuff.