|
I fully concur with the three environment
approach. I typically run Production, Replica (aka Testing) and Sandpit (aka
Development). One of the key tenants of my test environment is that when a
change is tested, it’s associated back out plan is also tested and I do
not sign off on any change that hasn’t got a back out plan unless the
risk associated with is accepted by those above. IMHO, this should be mandatory
for any test environment. We have a resource in Exchange that can be booked
the same way as a meeting room to ensure that everyone knows when it is free. From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of WATSON, BEN Those were my thoughts as
well on the issue and I’ve had to tell several people not to expect
production-like uptime. I really couldn’t think of a better way to
provide a test environment and there’s no way I’m going to build
multiple environments like this. Even though it’s a test
environment, it often requires more of my time to maintain than the production
environment. I may tell people to
create their own development environment as Jonathan suggested and allow
testing to be performed when they feel their app has outgrown a development
environment of their own creation. Thanks guys, it’s
good to know I’m on track here. ~Ben From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Hargraves It sounds like
you have a good test environment. The only problem is that people may be
scheduling their testing a little too tightly. They need to understand
that this is a *TEST* environment. That means it's in a constant state of
relative flux and that at any point in time, it could possibly go down for an
hour or even possibly a day or two. It will largely be available, but
it's not production and they shouldn't be expecting to receive the level of
support and uptime that they receive in the production environment. If
they expect that, they need to find a way to test outside your test
environment. If their schedules are slipping because of the availability
of the test environment, then they're not putting enough extra time into their
plans and need to start consulting you before deciding when to test and how
much time it's going to take. On 7/25/06, WATSON, BEN <[EMAIL PROTECTED]>
wrote: I was hoping to get some input from some of you to better understand how
you handle the design of test environments for application testing. For
example, I built a so-called "Offnet" which is a duplicate of our
production domain. We have a couple domain controllers restored from tape
backup, we have Exchange running, and various other production services using
the same domain name and hostnames providing for a very production-like test
environment. As time progressed, other production servers duplicated
themselves into this test environment and we now have quite a number of people
doing the majority of their testing in this environment. Unfortunately,
as more and more people have begun to use this environment for testing, we have
found that people are beginning to step on each others toes. For
instance, I used this test environment to walk through the domain upgrade to
2003 and when there was some downtime other people were unable to do their own
testing. So I was curious, how do you handle providing a working test environment
for people that need it? At this point, we are trying to determine a
better way for people to do their testing away from production. Thanks, ~Ben ---------------------------------------------------------------------------------------- This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind 1E Ltd to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ---------------------------------------------------------------------------------------- |
- RE: [ActiveDir] Test Environments Brad Smith
- Re: [ActiveDir] Test Environments Al Mulnick
