At my previous employer, we had this same issue with our external auditors:
I wasn't allowed to touch production. So we got a second machine. I still
had to push to production since I was the only System i programmer / admin
in the company. If you have Sox concerns, like Eric, or a large shop, maybe
it makes sense. In the small environments in which I have usually worked, a
complex ritual doesn't make sense.
That does not mean that there is no testing/quality assurance/archiving of
prior source versions. Just this morning I thought it prudent to add a
SAVE(*YES) to a printer file, but I archived the original source before I
did even that.
Jerry C. Adams
IBM i Programmer/Analyst
We're going to have the best-educated American people in the world. -Vice
President Dan Quayle
--
A&K Wholesale
Murfreesboro, TN
615-867-5070
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Lindstrom, Scott R.
Sent: Wednesday, April 25, 2012 3:45 PM
To: Midrange Systems Technical Discussion
Subject: RE: survey: frequency of in-house coded software enhancement
promotions to production
We run into this when auditors like to say 'programmers can't have access to
production' without understanding there are only two AS/400 people - the
application programmer and the sysadmin. And as the sysadmin don't let me
near the production data.
Scott
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Mike Cunningham
Sent: Wednesday, April 25, 2012 2:59 PM
To: Midrange Systems Technical Discussion
Subject: RE: survey: frequency of in-house coded software enhancement
promotions to production
I can agree with this when there are 20 programmers. Way too many people
poking around production. And if you have 20 programmers you probably have
dedicated helpdesk and support staff who do have access to production data.
But where you have 3 it's not practical. The same people writing the code
are the people who have to investigate an issue when someone calls and says
the system is wrong. If they can't access production data they can't figure
out what's wrong. Which in most cases is a data entry error or the user not
understanding the rules their boss required be but in the code
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Musselman, Paul
Sent: Wednesday, April 25, 2012 1:03 PM
To: Midrange Systems Technical Discussion
Subject: RE: survey: frequency of in-house coded software enhancement
promotions to production
I have to reply to the comment about programmers poking the production data
and programs directly.
NO! NO! NO!
My former job we used to "Load and Go" as one of our managers used to call
it. We tried to be good, but there were 'events.'
My current job we originally created a 'temporary' change management system
(the programs still exist and are sometimes used more than 20 years after
they were created). It allowed us to keep production and test data
separate, and during a promote the old version of the program was renamed
"just-in-case." Technical Support handled the promotions.
Then we got involved in a major Project. Programmers complained that the
technical support group was not keeping up with the promotes (which happened
any time of the day (and sometimes night)). Word came down from the head of
the department that programmers were to be allowed full access to the
production environment. The head of operations and technical support -very-
wisely got the 'word' in writing. And we turned the 20 or so programmers
loose.
It was a zoo. No controls over who was working on what program; we had
changes wiping each other out. Little or poor or no testing-- "It's just a
one-line change." Users were tripping over changes in program function.
Data barely survived intact.
Finally everyone realized that the mess could not continue. We looked over
Aldon and Soft Landing change management systems and went with Aldon, mostly
because it interfaced with a help desk system and we thought we might be
going in that direction. Other than that, at the time both packages were
pretty much the same.
We cloned libraries to make test environments, enrolled the programmers, and
locked down the production environment. Once the screaming from the
programmers (who could no longer touch the live environment) grudgingly
stopped, and the screaming from the users (reacting to the constant changes
and 'variable data') happily stopped, everyone pretty much agreed that this
was MUCH nicer-- things actually got tested; changes actually worked! Users
realized that fixing something 'now' is not as important as fixing something
'correctly.' Programmers realized that long nights and weekends to correct
an 'oops' seldom happened (knock on wood).
So, programmers, keep your grubby fingers off the live environment!
Paul E Musselman
PaulMmn@xxxxxxxxxxxxxxxxxxxx
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
