The Auditors aren't as concerned that one person is wearing a lot of
hats, as long as someone is verifying that the one person is not
doing things to line his pockets at company expense!
A change management system is nice, but it's even more important that
there's a wall between test and production, and that someone 'in
authority' makes the decision that code should be promoted--
1--program code is changed
2--someone tests to make sure the change works as intended - and
signs a document that it worked.
3--someone (not the same as #2) authorizes moving the code change to
production -
likewise signs- maybe countersigns the document in #2
4--The 1 Man moves the code to production
5--An audit report run over the production environment lists any
objects that have changed. In the event of an issue, produce the
paperwork that authorized the changes.
People who ask for a change must be willing to test the change and
sign a document certifying that the change was made and that it works
properly. This means they must actually TEST the change, and are
willing to sign their life away! Sometimes their reaction is "I
don't have time for this paperwork nonsense!" Stand your ground (I
know, it can get shakey if someone higher up the ladder is desperate
to get the change in place), and make them sign!
Next, someone in authority must be willing and able to authorize the
move to production. Sometimes, this person gets blurred with the
person OKing the changes.
In any event, you're going to need 4 source code libraries:
A) A developer's library, where changes to the code are made and
preliminary testing is performed. Programmers have full access to
this library.
B) A test library. The proposed changes are moved (By the one-man
band) from the programmer's library to the test library. They are
tested against a copy of the production files to see if the changes
worked. Programmers have read-only access to this library. If they
need to make further changes to their code, they have to copy it back
to library A, then the #1 Man moves it back to B.
C) An Archive library. Before the changes are moved to production,
the OLD production code is moved to the Archive library. just in
case. Ideally, you should keep multiple previous copies. We have an
ARCHIVE command. It moves things to the Archive library. But if the
object is already in the archive, that version is named to another
name, and then the changes are archived. Our system allows for up to
4 versions of old code (and objects): OBJECT, OBJECT$, OBJECT#,
OBJECT@. In the collating sequence, you'll see them in that
sequence. The CMS package will keep as many old versions as you like
(within reason).
D) A production library. Once tested and approved, the changes are
moved to production.
The One Man Band has full access to B, C, and D. ("I have allobject
authority, and I'm not afraid to use it!") But he only moves things
once he has the paperwork to justify it!
Making auditors happy is not an inexpensive proposition! It can cost
real $$ to buy a CMS package, or it can add extra paperwork and
manpower changes that make it possible to document the changes. Even
with a CMS package, someone has to turn the crank and make it work--
authorize people to check out the code, make changes, request a
promotion to production, etc.
The key is to get the auditors to approve whatever procedure you
create! Their goal is to document any changes and who authorized
them.
--Paul E Musselman
.
At 6:22 PM -0500 2/19/21, iseriesstuff wrote:
In order to be in compliance, our 1 man shop can no longer promote
code from test to production. We have been looking at packages to
assist but they are pretty expensive (>15k).
Any suggestions on more reasonable alternative that will make our
auditors and accountants happy?
midrange.com
