Re: development/test/prod environment mini-survey

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 software vendor.



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

b. Daily

"Emergency" promotes are allowed at any time, once approved by a department manager.
We try not to disrupt production users!

c. Weekly

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 production environment.
Programmers need to write a "blurb" describing the changes.

Limiting promotes helps keep the load on Technical Support under control as well!

d. Other

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
paulMmn@xxxxxxxxxxxxxxxxxxxx

Thanks!