CODEWITHSUNDEEP
ruby-on-rails-4continuous-integrationautomated-testsautomated-deploy
Dan L
Dan L

Reputation: 4439

Rails app, Continuous Integration/Deployment Environments

When developing, my team obviously uses development as our environment.

When we run automated tests, we use testing.

We also have staging and production environments, respectively used for our testers to check out features and the final "live" product.

We're trying to setup an internal CI server to run our automated tests against and to eventually assist with automated deployments.

Since the CI server is really running automated tests, some think it should be run in testing environment. However, in order for the CI server to actually be useful, my thoughts are that it needs to be run in production mode with as close-as-possible a mirror of the actual production environment (without touching the production DB, obviously).

Is there an accepted environment that a CI server should be executed under? production environment (with different DB) seems the only logical answer to me, but I may be missing something...

Upvotes: 0

Views: 234

Answers (1)

ekostadinov
ekostadinov

Reputation: 6940

Running any tests on PROD environment as you said

seems the only logical answer

but is not quite true. There are risks that your tests can seriously damage the actual environment/application to a point where you'll face a recovery option. After all the dark side of testing is to show/find that your software has not only minor bugs and it is working not as expected. I can think of at least these 'why not test production' considerations:

  • when the product is launched, the customer rely on it. Expecting that your software is working ()being already tested). Your live environment should do its job and not be loaded with tests. If the product misbehaved (or did not perform), the technical team have to be sent to to cover the damage, fix the gaps and make it run hassle free. Now this not only affected the product cost, but delayed the project deadlines in a major way. This will make a recursive effect at the vendors profits and next few projects.

  • the production or development team when completes a product development at their end, have to produce this test environment for testing team prior to loading their newly developed product on that environment for testing.

To me, no matter that you

also have staging and production environments

it is essential to use the Test one accordingly. Further more Testing environment should be (configured) as close as it gets to the Production. Also one person could be trying to test while another person breaks the thing that he has been testing. With out the two being separate their is no way to do proper testing.

Just to be full answer, your STAGE environment can have different roles depending on the company. One is that it can be the QA/STAGE environment that has an exact copy of production which is used for both QA and system testing (testing of the system when a lot of updates/changes or upgrade is going to go into production).

UPDATE:

That was my point too. The QA environment should be a mirror of the PROD. Possible solution about your issue with caching/pre-loading files onto staging/production is creation of pre-/post-steps .bat (let's assume) files.

In our current Test project we use this approach. In pre-steps we set-up files needed for test execution (like removing files from previous runs and downloading latest copies/artifacts). In post-steps we set up reporting files needed.The advantage is that your files will be collected and sync before every execution.

About the

not on the same physical hardware

in my case we support dedicated remote Test server. Advantages are clear, only thing that you need to be considered is that it'll require maintenance (administration).

Upvotes: 1

Related Questions