|
February 21, 2007
Source Control
I was once at a new site, getting the customer prepared for the PeopleSoft
installation. Someone asked me how we will handle source control
(i.e., version control of programs and objects to be customized).
I told him that in my experience, it might not be a big concern and
we could watch the situation to see if we actually needed anything along
those lines. He was sort of stunned. He had never heard of such a thing.
I was almost right. Probably about 90% correct. Or 70%. Anyway, the project was a
success. Today I would never make a statement like that. Version control is important and
actually has been an undercurrent of my posts these past few weeks. At any
normal development shop, there will be (or at least should be) some source/version control
management tool in place. What makes a PeopleSoft installation any different?
Well, it is different, in a way. While checking for customized objects for one customer,
I found just under 1 million objects in total (delivered and customized). Most of these,
oddly enough, were message catalog entries. If you ignore those, there are still half
a million objects left. These include traditional program files such as SQRs, but also
pages, record definitions, and all the rest. There is nothing really special about
a standalone file such as an SQR vs. an object that resides in the database.
So what's the point? With so many small, discrete objects, it just turns out in practice
that there is a smaller chance of one developer stepping on another developer's work,
especially if they are assigned to different modules or customization areas. Note that
I'm just referring to the statistical probability here. Of course you and I have seen
many cases of overlap. Source control is a good thing. How can it be done?
For SQRs and other standalone files, you could use an open source or commercial source
control system. For other objects,
the delivered PeopleSoft system includes a change control mechanism. I've described
that before (here),
but noted that it has a number of problems. In many cases it seems
that customers who start using it eventually drop it.
Another difference to note is that at most PeopleSoft installations, customized objects
migrate at different rates through the system. There is no concept of a "build". This
is not always true—some installations do schedule builds, especially if they
have multiple development environments (which is a big topic and out of scope for the
discussion here). But it seems less
common in general. This means that a change must be "locked" until it has migrated all
of the way to production. So we are not just talking about preventing two developers
from working on the same object at the same time.
A product such as Quest's Stat solves some of these problems by providing an object
locking mechanism that is more granular than
PeopleSoft's. It also isolates changes by copying them to a separate repository and
using that for the actual migration. This helps to "freeze" and protect
customized objects. The product is quirky and a little difficult
to understand at first, but effective when configured and used correctly.
Until next time...
|
