
(update : here are slides from our version control with PeopleSoft presentationat 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: PeopleCode, Products


http://psguyblog.blogspot.com/2006/02/version-control.html
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.
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.
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?
Could you expound on how you convert the objects into Subversion-friendly formats?