MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » September 2012

RE: development/test/prod environment mini-survey



fixed

Hi Joel
I feel like my question has been answered before, but I cannot find anything on it so here goes.
If you have no source on the production system, how can a programmer use debug when something goes wrong at 1:42 a.m.?

Alan Shore
Programmer/Analyst, Direct Response
E:AShore@xxxxxxxx
P:(631) 200-5019
C:(631) 880-8640
"If you're going through Hell, keep going" - Winston Churchill

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Thursday, September 20, 2012 4:00 PM
To: Midrange Systems Technical Discussion
Subject: RE: development/test/prod environment mini-survey

Joel,

You're point has some merit. There is extra work in keeping up the OS, PTF's and what not in a two box (or lpar) system. Some of that extra work has extra benefit - like testing your application under the new OS before loading the new OS on production.
We do NOT put source on production. The only reason we even have the RPG compiler on the production box was because one applications report writer generated RPG and compiled that. Which gets me to thinking, we aren't using that anymore...
I feel though that a separate machine reduces some boo boos due to job descriptions and what not which may be overlooked in creating test data and may have a production library in them.
Your points about DDM files and what not are valid. I brought them up in an earlier email.


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: "Stone, Joel" <Joel.Stone@xxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>,
Date: 09/20/2012 03:49 PM
Subject: RE: development/test/prod environment mini-survey
Sent by: midrange-l-bounces@xxxxxxxxxxxx



--5) What would be some reasons why this is a good idea (besides the
auditors told us to)?
-- "Guaranteed to not screw up the production environment."

I would argue that this "guarantee" is a lot less secure than the average
non-IT person might think.

If security is set up poorly on a two box system (TEST / PROD), then a few
DDM files or SNDNETF or a change management system can destroy stuff just
as quickly as on one box.

If security is set up well, then TEST/PROD on one box can be just as
effective imo.

My concern is that boxes are like babies - the first child seems like not
too much work. The second child arrives and it is 5 times the workload
for some reason!

Same with two Iseries boxes (or LPARS). Now simple stuff like a CPYF
takes a significant amount of effort instead of a trivial command.

Simple (one box) is easier to track, police, and control than complex
(multi-LPAR) imo.

But auditors and VPs will never see it that way anyways :)





-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [
mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Anderson, Kurt
Sent: Thursday, September 20, 2012 2:10 PM
To: Midrange Systems Technical Discussion
Subject: RE: development/test/prod environment mini-survey

1) Is dev/test/prod on same LPAR? Yes

2) Is dev/test/prod on same box? Yes

3) How frequently are promotions from dev to test allowed? D.

a. No restrictions

4) Does separating DEV from TEST require more time & effort for a
given development project?
This appears to be asking about the time to break dev/test/prod out
between boxes or lpars, and we don't do that, so I have no answer.

5) What would be some reasons why this is a good idea (besides the
auditors told us to)?
Guaranteed to not screw up the production environment.

For our testing, we use the library list to control our impact. A lot of
our testing uses STRDBG as an added measure to not impact any production
libraries.

-Kurt Anderson






Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact