Such question could be an indication of a poor architectural slicing into microservices. From What are Microservices?:
These services are built around business capabilities and
independently deployable by fully automated deployment machinery.
The key point missed in such case would be their independently deployable aspect.
The point could also be simply misunderstood: it doesn't necessarily mean that each microservice should be capable to perform its entire functionality by itself, it just means that it's able to gracefully bail when some other microservice its functionality depends on isn't available, maybe keeping track of "todo" stuff for later execution, when that microservice becomes available.
Seen from a different perspective: handling unavailability of external service dependencies should actually be part of each microservice functionality - so one could consider the microservice fully functional even when its runtime dependencies aren't satisfied :)
It's worth noting, I think, that in the above comments I'm referring to microservices unavailability regardless of its reason, be it deployment dependency order or something else (outages, for example).
Another thing to consider would be the finer difference between deploying the microservices and bringing them into action by switching the traffic to them. Switching traffic is often faster than the deployment itself, so the availability at the entire system level can be increased by first deploying all microservices and only after that performing the traffic switch for all of them.