RE: Source Code management - Migrating packages

I would agree on all of this if you have to comply with SOX but if you were non-SOX regulated, were writing software for use only by your company, and were the only programmer in your shop, would you still do this?

"five-minute changes" are not always bad. Say you have a values clause on a screen that prevents someone from entering some value you are not expecting and they need to be able to enter one new value. The field is only used in that one app to control how the data is sorted. You just need to change the values clause and the sort and the change is done, the user (who happens to be the head of the department that needs this changed made and has full authority to request and approve the change) goes away happy. Would you send this through 5 layers of process and approval just to make that change and add the cost of all that process to your company?

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of lgoodbar@xxxxxxxxxxxxxx
Sent: Wednesday, May 27, 2009 2:59 PM
To: midrange-l@xxxxxxxxxxxx
Subject: RE: Source Code management - Migrating packages

Source control is less about technology and more about proper controls
and discipline.
* No more "five-minute changes". This is a good thing. Each change
should have ramifications (i.e. tested).
* Do you have a test environment (either via library lists or separate
LPARS/systems), so you can test changes independently from production?
Have a process to "refresh" your test environment, or make it known it
is not an exact representation of production data.
* You should have a "change control form" with the intended
change/scope, and signatures for testing and approval into production.
We perform a monthly review of new objects created in our production
environment, and tie them back to a change request in the SCM or
document the exception.
* Make sure you get a source compare utility. (We use Aldon, but the
other packages should have similar capability.) I make it a habit to run
a compare from the QA environment versus production, so we can capture
which lines of source code were changed.
* You do get versioning. The SCM should have all previous Production
versions available for browsing. We are a small shop, so the need for
concurrent checkouts is minimal. Your SCM should provide a conflict
resolution process.
* You get a single point for browsing and managing your source code,
rather than the 5 copies of source in different libraries. Be prepared
to scrutinize each of the 5 versions to determine which one is the
"true" source for your production objects.
* Management (not just IT but organizational) should buy into the
process (again, no quick fixes) and understand the need for testing and
sign-offs.

These are my experiences as a company adhering to our procedures
developed for SOX. If you are privately held, you can do what you want.
:)

HTH,
Loyd

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of fbocch2595@xxxxxxx
Sent: Wednesday, May 27, 2009 12:13 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Source Code management - Migrating packages

Hi, my company has never used source code management software and/or a
change management system but wants to do so this year.?

How many vendors are there in this space...on the AS400 and if anyone
wants to share?pro's and con's that'd b/appreciated...or things to watch
out for.???

Thanks, Frank