Best Practice for Test and Production Environments

Question

In the company I work for, we have 2 environments: testing and production. We are not currently launching a new environment due to cost.

Here is the procedure we follow: a business makes a request for a function, its development and deployment in a test environment. Then business tests (UAT), and if everything is in order, this feature will be included in the next production deployment.

The problem is detected in the test database. Developers see the test environment as their playground, and sometimes they put the DB in its initial state for testing purposes. On the other hand, business people believe that the test database should be stable and should not be reset. We would like to solve this problem and decide whether the test environment should belong to a development team or a business group. (Developers do not want the business to bring the nose into the test environment, but the business group pays for the servers.)

What is the best practice for environments? Can you recommend an article about this?

Answer 1

Our company also has two databases, a test and production database. The test database is mainly used for testing by developers, but sometimes for business tests. This database is updated daily using an actual copy of the production database. Thus, this database can be both a playground and a serious test database. But the third, development, database is the best option. We had one, but it is broken at the moment. But when you get one of them, you have to make sure that it is updated often enough. When developers use it as a playground, it will deviate from the production environment, and its data will be both old and current. Because of this, developers will not be able to recommend themselves well. Therefore, be sure to update this database periodically (perhaps daily or at least once a week).

Answer 2

If possible, give each developer their own database on their local computer. Thus, she can do whatever she wants with her without affecting anyone. This should significantly reduce her desire to play with the test database, providing a more stable environment for the UAT business.

Answer 3

I worked in many companies, each of which has a different set of environments, the one that I most had 5 environments:

1) Local: basically your car. This is where you code and check your changes before you even ask an expert for a review.

2) Dev: If for some reason you can’t test your code locally (dependency problems mostly: "My code is not compiled in my machine, but it compiles fine in Jenkins / Bamboo / Travis"), then you click your changes to your function branch in Git and make Bamboo compile it and deploy it to the Dev server where you can test (you are still not sure that it will work, so there is no expert evaluation yet).

3) Stage: you think your code is working and you like the way it looks. You create a Pull request so that your peers can look at it before it is merged with the main branch. Here they make comments and fix possible problems, since you are more confident in your changes, you make Bamboo deploy it to the Staging environment, where there is more “stable” code, and more realistic data is stored in any database. After deployment, another developer / tester can verify that your changes really work and make you “QA Failure in Interim Rendering”.

4) Stable: Well, now you are completely sure that your changes have been working since you were deployed to Staging and nothing broke. You merge your branch into master and Bamboo compiles the master and deploys to other servers in a stable environment (no one needs to merge to master until you complete the deployment in Production to avoid merging unrelated merges). This environment should be a replica of production conditions, data, code, and server. Here you indicate your changes to your manager, product owner or responsible person for confirming your work before sending it to production. You get final approval, everything is fine, you are sweaty, you worked 30 days in a row to make this change, your wife divorced you, but you are very sure that he works great.

5) Production: where customers connect to the consumption of company services or the final assembly of your software to be sent to customers. With a few clicks of the mouse in Bamboo, you make it deploy to production servers or compile the final assembly. He is green, everything looks fine. You check that Splunk is looking for mistakes, everything is fine, life is good, you drink another sip of coffee before you leave, you go home and sleep all weekend with a dog by your side.

This is a happy ending, because since so many “test” environments provide quality, no changes are made until EVERYBODY (and not just you) is completely sure that the changes work.

Answer 4

I believe that in order to create an environment strategy that supports all ALM / SDLC actions, there must be 4 requirements:

1) Development environment: let Dev play with new code / concepts and usually unit test with some basic integration tests using stubs and drivers. This environment should have change management procedures and, as a rule, should not be anywhere on the same scale as production. Here, the Dev team can create and reset settings as needed.

2) Interop environment: where system integration can be additionally tested and increased the possibility of non-functional testing. I can be resilient env with more scalability than Dev. I would see that in this environment more stringent change control and management. The test would perform system integration and testing in this environment.

3) Reference architecture: this is what some may call a preliminary work, but in essence it is the same as production in terms of scale and sustainability. This would lead to product-related change control and management procedures. This env will support further testing activities, especially full-scale performance testing, fault tolerance, as well as operational failures and troubleshooting operations after the product launches for customers.

4) Production: this environment will support live customers, and therefore testing activities will be limited as soon as this happens. It will be fully managed and have strict change management and configuration management processes.

Hope this helps