Return to Answer

The only way to reduce the risk of breaking things in production is to test new releases before deployment. Fullstop. And if your budget for testers is small, try to create as many automatic tests as possible. Learn about unit tests, automatic integration test, TDD, and train your team with these techniques - these are things which can be established perfectly in a small team. And if you believe testing is still to expensive, compare this to the costs when your production stops for one day.

However, no test can bring the risk of breaking things completely to 0. So what you should always have is a good fall-back strategy - if it turns out the new release did break something unexpectedly, you should always have the possibility to switch back to the previous release of your software as soon as possible. This is mostly an organizational task, for example: make sure every release is archived somewhere, make sure the people who know how to install the software or the previous release are not going on vacation the day after deployment, make sure the database is backuped immediately before deployment, simplify the installation process, and so on.

Here is a former PSE question which deals with the question what to do when things break in production. Note that this post assumes there is a test environment.

The only way to reduce the risk of breaking things in production is to test new releases before deployment. Fullstop. And if your budget for testers is small, try to create as many automatic tests as possible. Learn about unit tests, automatic integration test, TDD, and train your team with these techniques - these are things which can be established perfectly in a small team. And if you believe testing is still to expensive, compare this to the costs when your production stops for one day.

However, no test can bring the risk of breaking things completely to 0. So what you should always have is a good fall-back strategy - if it turns out the new release did break something unexpectedly, you should always have the possibility to switch back to the previous release of your software as soon as possible. This is mostly an organizational task, for example: make sure every release is archived somewhere, make sure the people who know how to install the software or the previous release are not going on vacation the day after deployment, make sure the database is backuped immediately before deployment, simplify the installation process, and so on.

Here is a former PSE question which deals with the question what to do when things break in production. Note that this post assumes there is a test environment.

The only way to reduce the risk of breaking things in production is to test new releases before deployment. Fullstop. And if your budget for testers is small, try to create as many automatic tests as possible. Learn about unit tests, automatic integration test, TDD, and train your team with these techniques - these are things which can be established perfectly in a small team. And if you believe testing is still to expensive, compare this to the costs when your production stops for one day.

However, no test can bring the risk of breaking things completely to 0. So what you should always have is a good fall-back strategy - if it turns out the new release did break something unexpectedly, you should always have the possibility to switch back to the previous release of your software as soon as possible. This is mostly an organizational task, for example: make sure every release is archived somewhere, make sure the people who know how to install the software or the previous release are not going on vacation the day after deployment, make sure the database is backuped immediately before deployment, simplify the installation process, and so on.

The only way to reduce the risk of breaking things in production is to test new releases before deployment. Fullstop. And if your budget for testers is small, try to create as many automatic tests as possible. Learn about unit tests, automatic integration test, TDD, and train your team with these techniques - these are things which can be established perfectly in a small team. And if you believe testing is still to expensive, compare this to the costs when your production stops for one day.

However, no test can bring the risk of breaking things completely to 0. So what you should always have is a good fall-back strategy - if it turns out the new release did break something unexpectedly, you should always have the possibility to switch back to the previous release of your software as soon as possible. This is mostly an organizational task, for example: make sure every release is archived somewhere, make sure the people who know how to install the software or the previous release are not going on vacation the day after deployment, make sure the database is backuped immediately before deployment, simplify the installation process, and so on.

Here is a former PSE question which deals with the question what to do when things break in production. Note that this post assumes there is a test environment.

The only way to reduce the risk of breaking things in production is to test new releases before deployment. Fullstop. And if your budget for testers is small, try to create as many automatic tests as possible. Learn about unit tests, automatic integration test, TDD, and train your team with these techniques - these are things which can be established perfectly in a small team. And if you believe testing to still to expensive, compare this to the costs when your production stops for one day.

However, no test can bring the risk of breaking things completely to 0. So what you should always have is a good fall-back strategy - if it turns out the new release did break something unexpectedly, you should always have the possibility to switch back to the previous release of your software as soon as possible. This is mostly an organizational task, for example: make sure every release is archived somewhere, make sure the people who know how to install the software or the previous release are not going on vacation the day after deployment, make sure the database is backuped immediately before deployment, simplify the installation process, and so on.

The only way to reduce the risk of breaking things in production is to test new releases before deployment. Fullstop. And if your budget for testers is small, try to create as many automatic tests as possible. Learn about unit tests, automatic integration test, TDD, and train your team with these techniques - these are things which can be established perfectly in a small team. And if you believe testing is still to expensive, compare this to the costs when your production stops for one day.

However, no test can bring the risk of breaking things completely to 0. So what you should always have is a good fall-back strategy - if it turns out the new release did break something unexpectedly, you should always have the possibility to switch back to the previous release of your software as soon as possible. This is mostly an organizational task, for example: make sure every release is archived somewhere, make sure the people who know how to install the software or the previous release are not going on vacation the day after deployment, make sure the database is backuped immediately before deployment, simplify the installation process, and so on.