-1

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.

closed as too broad by Robert Harvey, Dan Pichelman, user40980, GlenH7, gnat Sep 23 '14 at 3:17

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    I think this is very dependent on environment. Is it web, desktop or app? Java EE, .NET, ruby or node.js? Cloud deployment or custom servers? How is env. config handled? Please elaborate a bit – Petter Nordlander Sep 21 '14 at 18:46
  • Virtual machines are very nearly free. Use them as much as you can. – Michael Hampton Sep 21 '14 at 22:21
4

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.

1

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
    "The cost of mistakes in the live environment is more expensive than paying for a test environment up front" - though this argument is probably true for lots of systems, I don't like it, because it is somewhat academic. It ignores that there are very different kind of systems of different scale, with very different costs for a production stop and very different costs for a test environment. Sometimes it can be cheaper to risk certain failures in production, when you are able to detect and repair such failures very quickly. – Doc Brown Sep 21 '14 at 20:14

Not the answer you're looking for? Browse other questions tagged or ask your own question.