How can one move development / test code into production, and not end up breaking the functionality in Production environment? I am working with a small sized company, so they don’t have a budget for a Test environment.
My goal is to move code to production and not compromise the user experience. Given that in a production environment, I can’t really create dummy records to process, because the application involves 3rd party vendor interaction.
Any suggestions? For this particular example, let’s say web, MS.Net, non-cloud.
But even if these is a general best practice on how to move code, I would be interested in learning that. Alot of C level people who are not techies, expect things to run smooth, so when stuff breaks, lotsa finger pointing starts.
2
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.
they don’t have a budget for a Test environment
If they have the budget for a live environment and a developer, they can find the budget for a test environment. The cost of mistakes in the live environment is more expensive than paying for a test environment up front. A test environment can be a scaled down clone of a live environment. In a virtual setup like AWS the test systems can be turned off when not in use, costing $0 most of the time.
Also work with the 3rd party vendors to use their test environments or at least set up test data in their live environment.
1