How do you test a deployment without affecting production users?

Best practice follows a two stage approach.

Have a pre-prod/staging environment that is configured the same as production. This is easy if you have your infrastructure defined in code, aka Infrastructure as Code (IaC). Deploying to your staging environment will give you early indications of possible deployment failures.

Deploying to production can then be done with less risk by using a canary deployment. This is where you deploy the new code to a limited number of servers, to test a new feature without affecting the whole deployment. A similar approach is to have a feature behind a switch, and enable that for a subset of users.

Either approach reduces the blast radius should anything go wrong.

How will you know if your deployment has gone awry? Your monitoring should tell you this through 500 errors or some other logging and metrics collection.

For the trickiest case — a change that only breaks under real production load or data shapes — canary or shadow traffic (mirroring a copy of real production requests to the new version without returning its response to the user) catches issues staging never will, at the cost of extra infrastructure.