(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).