Deploying new software versions of your software should not give you anxiety.

There are 4 sources of risk when it comes to deploying new software versions: code, data, configuration, and unexpected user workflows.

First, you need what's called a staging server. A staging server is a production environment that has configuration that is optimally close to your REAL production server where the real work is being done. The reason why you need this is because when you're writing code in the development environment or writing tests in the test environment, those configurations are different from production.

ALWAYS deploy and QA your code to a staging environment and test it in a setting that is as similar as possible to your production one.

This nullifies your configuration risk.

Next, when you're testing a new feature on staging, always test it with respect to BREAKING the feature. Developers are in the mindset of making things WORK when they're coding. Users are 100% going to use your application in ways that the developers did not code against. Your intent with QA is to BREAK the new feature set. If you QA with this mentality, you have protected yourself from "unexpected user workflows".

Finally, on each deploy to your staging environment, copy the production data over to it.

The reason why this is critical is because unexpected data is another major source of risk when deploying software. In a proper environment, developers are working against fake data on their computers. But real-life data has unexpected side effects.

Put your new code on a staging environment, try to break it, and use production data when testing it. If you do these 3 things, the level of risk for your new code deploys will drop dramatically.

How do you deploy your software safely?
—
Follow me online here:

LinkedIn: https://www.linkedin.com/in/joshua-pl...
TikTok: https://www.tiktok.com/@joshuaplicque/
Youtube: https://www.youtube.com/c/JoshuaPlicque/