(update : here are slides from our version control with PeopleSoft presentation at OpenWorld 2007)

(update 2 : flash demo posted here)

As Larry mentioned in a post a few months back, we never managed to actually ship version control for PeopleTools. It had become a joke within the PeopleTools Product Management group that getting your feature prioritized below version control was a good way for it to never see the light of day.

But why is version control for PeopleTools objects so hard? Why were we even planning on building version control at all when there are so many other tools out there?

Well, the main reason is that a large majority of the application exists as meta-data within the database, and not in the form of text files that most version control systems expect. We did some internal benchmarking of the lines of code across our entire suite of applications and toolset and came in at approximately 10% of SAP. We were around 18 million LOC, SAP was somewhere north of 160 million (I never figured out the Oracle number). Of course, that was only counting actual lines of code, not all of the meta-data that lived in the database.

There are lots of benefits to being meta-data driven (a topic for another blog post someday), but lots of choices for version control are not one of them :-) And people do want to version control their application definitions, whether they are defined as code or as data. Hence, the long standing desire for version control for PeopleTools definitions. The change control feature that was shipped in PeopleTools 7 was better than nothing, but that’s not saying much. There’s a reason that you won’t find many PeopleSoft customers using that.

A lot of people don’t realize that version control is a tough problem to solve. Eric Sink of SourceGear has written an excellent “Source Code HOWTO” that provides the best coverage of the topic that I’ve seen. It treats you like you are smart, but not familiar with source code control and gets into a good level of detail without overwhelming you.

That writeup really highlights the amount of work that goes into building a version control system. If you read it, then you’ll realize that PeopleSoft needed to either provide this functionality or be able to hook into a system that did.

Aside from the normal challenges of being dependent on 3rd party stuff in your shipping products, the other challenge of integrating in an “off the shelf” version control system is that they version lines of text, as opposed to data. Not an insurmountable problem, but definitely a challenge.

One thing that some customers did was to use Quest Stat for project management. Stat handles versioning of PeopleTools objects quite well, although they never got as much traction as they might have because Stat handles a lot of things in addition to version control, so it was overkill for a lot of folks.

What we’ve been doing internally for our own source code management within Grey Heller is to convert PeopleTools objects to and from their delivered representations into text formats that we can check into Subversion, which is the source code control system that we use (we also use Trac, which can sit on top of Subversion to provide additional functionality). This has saved me personally on a number of instances from overwriting other people’s changes in our development work.

In a nutshell, we export a project, slice up the export file pretty heavily into it’s constituent parts, do a lot of sorting and other manipulation so that each line of text matches up with a specific data attribute that is “interesting” from a source code control perspective. This depends on PeopleTools 8.4x (the older project export files were in a binary format).

So now I can browse what changes were checked in, diff those changes from previous versions, etc. via my Blackberry while I’m out at the beach via the internet. All I need to do is actually go to the beach :-)

We also use Subversion/Trac for managing other non-PeopleTools definitions as well. Highly recommended.

It’s funny when we tell people that we know that we’ve built version control for PeopleTools. They generally freak out a bit, knowing that if we were to ship this it would cause the world to come to an end :-)

Unfortunately I have no source code snippets to share in this posting on what we’ve put together so far. It’s still in such a rough state that you have to really understand how it all works in order to use it. Which is OK for us, since we’re still a small company, but since it’s just something for internal use right now and not an actual product that we’re selling, it doesn’t rise up to the top of the priority list.

If you catch me in person at an event sometime ask me about it and I’ll try to explain more and/or give a demo (assuming I don’t get around to blogging more about it in the meantime).

Labels: ,

10 Responses to “PeopleSoft Version Control”

  1. Sasank Vemana says:

    how much are we looking at roughly for purchasing this product?

  2. KEVIN says:

    We are already using Subversion and Trac for development efforts outside of PeopleSoft and have used Stat for PeopleSoft objects. We would like to phase out Stat, however. The current hurdle is gaining the visibility, as you put it, into each object for diff functionality.

    Could you expound on how you convert the objects into Subversion-friendly formats?

  3. Chris Heller says:

    We have been using Subversion and Trac internally at Grey Sparling for our own development purposes since we started the company. We convert the PeopleTools objects into formats that work better with Subversion (or other “standard” version control tools).

    So when we check-in a project, we get visibility into each PeopleTools object singularly as well as as an entire project. So we get diffs, etc. for each PeopleCode program, SQL object, HTML object, record definition, page definition, etc.

    That works quite well, and there are a wealth of other tools that work well with Subversion and Trac.

    Recently we have been building plugins for working inside the PeopleSoft client/server tools, such as providing 2 tier single signon support to go along with our Desktop Single Signon product (which is sort of funny after all the years of saying “no code on the client” :-)

    Once we had built out that infrastructure, then it made sense to convert the existing version control work to run natively inside Application Designer, which makes it a lot easier to use.

    Are you already Subversion and Trac for other development in your organization? or are you just planning on starting with it for PeopleSoft development work?

  4. KEVIN says:

    We are looking at using Subversion/Trac for our PeopleSoft versioning solution. I was wondering if you could provide me more information on how exactly you use it?

  5. Anonymous says:

    PeopleTools object versioning does indeed present some challenges. However, it has been successfully done by a group of PeopleSoft professionals who developed Phire Architect Application Change Mangement software. It is being used by some very large companies to version and migrate files and PeopleTools objects.

  6. Chris Heller says:

    In PeopleTools 8.4, there was a good amount of effort that went into having Application Designer not be so dependent on the exact structure, but that was mostly around project import and export.

    Compare did get some enhancements in PeopleTools 8.46 though. You can now compare directly from a project file to what is in the database without importing it. That means that you could take a project that someone created on, say, PeopleTools 8.42 and compare it with an 8.46 system without having to upgrade the 8.42 system or having an extra 8.46 system to import it into and then compare. It doesn’t help going in the other direction though (taking an 8.46 project and comparing it with an 8.42 database)

    As for changing the C++ code based on the data structures, it could be done, but then you’d also need to include information about the semantics of the objects being compared. Most of that semantic knowledge lives inside of that C++ code and is not accessible unless you are an actual developer on the PeopleTools team.

  7. Chris Heller says:

    Thanks Heller,

    I totally understand that the PeopleTools compare from version 8.x is C++ driven but just thought that this (making the C++ code Tools independent, shouldn’t be much tough as I can see the rel-scripts can provide all the table structure differences, the peopletools data mapping and most importantly how the PeopleTools data has to be changed between different PeopleTools version….gave this info just to make sure that the others don’t loose sight of what I’m pointing to ;) ) should have solved most of the version control problem which PeopleSoft has gone through.

    Another great advantage is that we could have easily compared different Application releases and hence obtaining the Gaps and the new delivered functionality (We have to do a PeopleTools upgrade for this and I’m against it).

    Thanks for your feedback.

  8. Chris Heller says:

    Hi PS-Guy. I just posted some thoughts on your site.

  9. PS-GUY says:

    I have certain thoughts on this, kindly look into the post. I have made certain references to your post. You can look into it following the link below,

    http://psguyblog.blogspot.com/2006/02/version-control.html

  10. Derek says:

    We’re a Quest STAT shop here. The team I used to work on (sPro) used it and my new team HCM/Payroll is in the process of implementing it. It seems to work pretty well with our team structures.