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
Sent: 25 July 2006 21:45Subject: RE: [ActiveDir] Test Environments
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
Sent: Tuesday, July 25, 2006 12:04 PM
To: [email protected]
Subject: Re: [ActiveDir] Test Environments
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.
It may sound like I'm being harsh on them, but it sounds like they are really expecting too much from a test environment and that's because there isn't enough consulting occuring. It really sounds like you need to possibly make a "Testing calendar" so that everyone (or maybe even just you) have a list of applications that are being tested in the environment and when schema updates and other items which can affect multiple tests that are ongoing occur, the relevant persons can be notified so if they need to reschedule their testing or adjust their testing schedule, they can.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.
----------------------------------------------------------------------------------------
Brad brings up some of the more important change control concepts.
Remember that a dev environment *is* production for a developer. It should be controlled to some degree.
I've often advocated many more test environments. Everything from sandbox (try whatever you want, but no control) to pristine production-mirror (hands -off - it's identical 'cause it was recently restored to make it so). Scalability labs have some steep hardware requirement costs (do you really want to know how well that app will perform on x hardware in our environment?) and is highly similar to production/pristine. There are several environments in between because of the exact issue you discuss. For example, you might have to duplicate a production like environment to facilitate development of workstation images and deployment scenarios, but that type of work might impact somebody doing web design. What to do to meet both? Create both. With virtualization you can make this happen more cost effectively. You can't virtualize the more pristine (all of it anyway) because you may be testing the upgrade on the DC's or the other app servers. That should be very similar and highly isolated.
My $0.04 anyway. I advocate a high level of testing where possible and where impact is otherwise not tolerable.
On 8/2/06, Brad Smith <[EMAIL PROTECTED]> wrote:
- RE: [ActiveDir] Test Environments Brad Smith
- Re: [ActiveDir] Test Environments Al Mulnick
