That's my poing Dave, and if you have code which alters behaviour based
on it's detection of it's environment (dev, test, prod), the code will
care about which environment it's because that determines its very
behaviour.
This means that even if you move a non-production configuration into
production by mistake the application may still appear to work due to
the behavioural changes it makes based on its' detection of its'
environment when it's is actually configured incorrectly.
Al.
P.S. A number of the QA guys I've worked with use simulated endpoints
rather than altering the application code. They use combinations of DNS
changes, scripted clients, dummy message queue listeners, and mock ups
of external systems to ensure that the QA configuration is as close to
production as possible.
Dave Newton wrote:
--- On Sun, 6/29/08, Al Sutton <[EMAIL PROTECTED]> wrote:
Imagine the fun of having an app which only sends live
messages when your in production. The QA team run all
the tests they have in a QA labe, they all pass because
the app decides to only use test data, they move the app
and configuration onto the production server, nothing
works.... bad bad bad idea.
Why would a non-production configuration be moved onto the production server?
Why wouldn't the production configuration also be tested (not necessarily by
QA)?
What are the options? All configurations have to be tested. The *code*
shouldn't care which environment its in, no?
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
