There are two common techniques for implementing slow, controlled deployments, namely canary deployments and blue-green deployments. Both techniques are effective if used properly. This document makes no effort to argue for/against either of these methods.
Canary deployments are a technique to reduce the risk of introducing new software versions into production by slowly rolling out the change to a small subset of traffic before rolling it out to the entire infrastructure. As the operator gains confidence in the new version, they can start releasing it to more servers/instances in your infrastructure, and thus routing more traffic to it. Canary deployments last until all traffic has been routed to the new version. If the operator finds any problems with the new version, the rollback strategy is simply to redeploy the old version on the small subset of services/instances until the problem has been resolved.
Blue-green deployments approach slow and controlled releases by ensuring the operator has two nearly identical environments, blue and green. At any time, one of the environments is “live” and receiving traffic. For the sake of example, let’s assume we have a “live” blue environment. In order to release a new software version, the operator deploys the new version to the non-live green environment. Afterwards, the operator re-routes traffic from the blue environment to the green environment. Once complete, the green environment is now “live” receiving all traffic, while the blue environment is now idle. Blue-green deployments also give a means of rapid rollback - if anything goes wrong, the operator can switch back to the previous environment.