At 6:57 PM +0000 9/18/12, Stone, Joel wrote:
My company is considering separating dev from test.
For this survey: DEV is where programmers play; TEST is where
business analysts and users try out new stuff, PROD is where the
money is made.
Please respond only if NOT a software vendor - Im sure rules are
much different when there are thousands of installs involved at a
I would like to inquire how other iseries shops are handling this.
1) Is dev/test/prod on same LPAR?
New systems with multiple LPARs in our future.
Prod will be one LPAR
Dev/Test will be a 2nd
2) Is dev/test/prod on same box?
Dev/Test share the same machine, along with a MIMIXed copy of
most of Prod.
Programmers can read but not touch Prod.
3) How frequently are promotions from dev to test allowed?
a. No restrictions
"Emergency" promotes are allowed at any time, once approved
by a department manager.
We try not to disrupt production users!
Most promotions are performed early Saturday AM (ie 6-10 AM).
The idea is that users
shouldn't have to deal with lots of 'random' changes to their
Programmers need to write a "blurb" describing the changes.
Limiting promotes helps keep the load on Technical Support
under control as well!
4) Does separating DEV from TEST require more time & effort for
a given development project?
We have multiple levels of test environment, plus additional
test libraries for special uses.
These are standing environments, and don't have to be built
for each project.
Data can be refreshed as needed.
We try to keep developer testing away from user testing (with
various degrees of success!).
The degree of Test required depends on the extent of the changes!
5) What would be some reasons why this is a good idea (besides
the auditors told us to)?
Creating an additional environment to keep DEV and TEST
separate is the hard part-- but once it's
done, maintaining them is relatively easy.
We use Aldon CMS, which creates a hierarchy of test
environments (programmer library / dev / test / live).
The use of library lists makes it relatively easy to keep
track of changes in effect at each level.
If you're talking about SOX auditors-- I believe that the
corporation being evaluated gets to write its own
standards manual. The auditors just make sure the corp is
following its own rules!
--Paul E Musselman