Visual page diff/merge was one of the cool new features added back in PeopleTools 8.48. Visual page diff/merge lets you see two instances of the same page definition side by side and step through the differences visually. It's a huge improvement over just seeing the page field attributes in the classic PeopleTools compare reports.

We've recently added native support in our Version Control for PeopleSoft product to support this, but the last few people that we have shown our integration work to weren't even aware that Application Designer even had this functionality this at all. So, to kick off 2010 we'll take a look at how visual page diff/merge works.

Visual Page Diff

The page that we'll use is from our PSIDE Helper product. The purpose of the page is to allow someone to select different PeopleTools objects in the current database and see how to generate a URL opens that object in Application Designer. The different prompt fields that are displayed are hidden/unhidden based on the definition type that you have selected. Here is what it normally looks like.


We went ahead and made some changes to the page so we have some differences to look at. The page below is what is currently in the database that we are logged in to.


In Application Designer select Tools -> Diff/Merge Page. This menu item only appears when you have a page definition open (which is probably part of the reason that this feature is not more widely known). You'd then select your target; either another database or an Application Designer project export file.


This opens up a window that shows both page definitions side by side, highlighting the fields that are different in some way.


The toolbar in App Designer gets four new buttons when the visual diff/merge is active. Two are for navigating up and down through each field that has differences, and two are for choosing whether to keep the current field or merge in it's definition from the target (there are corresponding menu items as well).

As you navigate up and down between the changed fields, the properties values dialog box changes to show just what properties have changed for the current field.

The properties dialog does not show the field name (it just shows field ID at the top), but the currently selected field does get a dashed outline to help you see which field is the current one. In the screenshot below the bottom field ("Field Name") has been selected.

It doesn't show as well via static screenshots, but as you navigate up and down through the fields in App Designer, it's quite usable.

Visual Page Merge

Seeing the differences in their visual context is nice, but how about the merging? Let's suppose that we wanted to merge back the fields for Component and Market, but not for the others. Click the down button until the Component field is selected.


Then click B in the toolbar and the Component field from the target is merged into your current page definition. The screenshot below shows the Component field back in it's original position on the left side. The properties dialog shows that the properties that were different when we started the merge are now the same. Note that the merge is at the field level, not property by property.


If you wanted to put it back before saving, then just click the A button in the toolbar and the Component field would move back to the right side of the page definition.

To do the same for the Market field, just click the down button once more to select the Market field.



Then click the B button.


Much better than trying to move fields around and set properties manually when there are differences!

At this point you can close the window and since there were changes, you'll get prompted to save them.

This saves the changes to the PeopleSoft database that you are logged into just like you had modified the fields manually.


Version Control Support for Visual Page Diff/Merge

As I mentioned in the beginning we have added native support for using a Grey Sparling Version Control repository as the target for doing the visual diff/merge.



By selecting "Version Control" as the target, we will automatically grab the page definition from the Version Control repository and use that. In the screenshot below we're using the latest revision (colloquially known as the HEAD revision) from the DEV branch of version control.


You're not limited to just using the latest revision in version control though. You can pick any earlier revision that has been committed to version control. You can also pick different branches from version control. Maybe you want to use the revision that was migrated to production last month for doing the diff/merge; not a problem.

Labels: 2010, Upgrade, VersionControl

In our previous blog post we introduced a Continuous Integration server called Hudson to run automated tests against a PeopleSoft system for us. We didn't really get into any test content itself though; we just ran some dummy Application Engine code to show how Hudson can work with PeopleSoft.

Now that the framework piece is in place though, we can begin creating tests. For this blog post we're going to focus on testing functional aspects of PeopleSoft, not performance testing.

Functional Testing Webinar

Before getting into the details, I wanted to point out that we have an upcoming webinar on this exact topic on May 20th, so if you're interested be sure to register for that.

Functional Testing Options

There's a variety of different ways for doing functional testing. Dave Bain from Oracle recently announced the availability of a PeopleSoft specific unit testing tool called PS/Unit. We'll look at PS/Unit in an upcoming post, but if you're not familiar with unit testing you can think of it as testing the lowest level "units" of your code.

Another approach is doing browser-based testing. Browser based testing means having automated tests that drive an actual web browser instance and simulate an actual user's behavior. The primary benefit of browser based testing is that you can be reasonably sure that you are testing PeopleSoft as your users will be seeing and working with it.

In fact, browser based testing can be thought of as automating the way that most people test their PeopleSoft implementations today; which, sadly enough, is by having some of their functional users run through a series of manual tests in their browsers. Expensive, error-prone, incomplete are some of the adjectives that spring to mind when describing manual testing. Not to mention just the hassle of trying to get the functional users to participate in testing. They may be willing to participate once or twice, but if you need to incorporate any additional testing beyond your original project plan, it is a major hassle.

Browser based testing

Back in the old client/server days, PeopleSoft used to bundle SQA Robot (later purchased by Rational/IBM) because it understood something about the Windows controls used PeopleTools for creating the UI. These days the PeopleSoft UI is HTML/Javascript and there are lots of freely available tools that we can use for testing.

One tool that we like for functional testing via the browser is called Selenium. Selenium can run tests across multiple different browsers, and there is a plugin for running Selenium tests via Hudson so we can automate the execution and management of our automated tests.

Getting Started with Selenium

Before we get into running our Selenium tests in Hudson, we need to create some tests. The easiest way to do this is with the Selenium IDE, which is a Firefox plugin and can record, edit and debug tests. The tests themselves can be executed in other browsers, so we're only dependent on Firefox for our initial test development.

So if you're not already in Firefox right now, switch over to Firefox and launch the Selenium IDE plugin installer. Here is the current link, which is for version 1.0 beta 2, but you can check their download page as well to see if there are updated versions available.

Your First Test

After installing Selenium IDE, you can launch it from the Tools -> Selenium IDE menu in Firefox.



When Selenium IDE launches it automatically starts in recording mode, so you can switch back to your main Firefox window and begin working. For this first example, I

• Entered the URL for the PeopleSoft signon page


• Typed in the password (the user ID was already defaulted for me)


• Clicked "Sign In"


• Waited for the portal home page to load


• Clicked the "Logout" link

Then I switched back to the Selenium IDE window and stopped recording by clicking the Red button in the recording toolbar (unfortunately there are not keyboard equivalents for the Selenium recording toolbar). Let's see what Selenium captured for us.



The first thing to notice is that Selenium has captured http://www.gsdemo.com as the base URL. All URL commands will be relative to this (there are some extra things to know if you plan to write tests that go across more than one base URL).

The first actual command that Selenium has captured is the open command. All Selenium commands take the form of Command, Target, Value. Here the target is the URL /psp/ps/?cmd=login, which gets combined with the base URL. This opens the login page.



Next is the type command, where we entered the password. In this case Selenium realized that the pwd DOM ID for the password field was the simplest choice that would work. You'll notice that the Target editbox has become a dropdown box which shows some alternate methods of referencing the password field.



The next command is the clickAndWait command. Selenium recognized the Sign In button via it's DOM ID of Submit and used that.



The last command is also the clickAndWait command, but when we logged out, there was no unique DOM ID that was associated with the Logout link, so Selenium recognized the click by noting that the link text was Logout (eagle-eyed readers will note that the logout text in this environment has actually been customized from an earlier blog entry).

At this point we can repeatedly click the play button in the Selenium recording toolbar and watch the browser login and logout. There are actually two play buttons, one is for the current test case and one is for playing back an entire test suite (which is many test cases grouped together). In this instance it doesn't matter, but once you actually create test suites, then you'll want keep them straight in your head.

If you have any problems at this point playing back the test, you can try adjusting slider control in the Selenium IDE toolbar towards the "Slow" end. This causes Selenium IDE to wait a bit longer for commands to show some results.

Modifying the Test

Each of the commands that Selenium captured for us is modifiable, including being able to delete it. So to make our test a bit more exciting, we highlight the last command (the clickAndWait command that logged out) and delete it, since we don't want to logout just yet.

Then play the script again. This time when the script finishes you will be left on the portal home page (since we're not logging out). Pressing the Record button will start recording again at the end of the script.

This time we will navigate via the portal menu navigation to PeopleTools -> Security -> User Profiles -> User Profiles. Once the User Profiles component search page is up, we type in PTDMO and then press the Search button.

Before playing back this script, I made one manual edit. I changed the very top command from navigating to cmd=login to cmd=logout. PeopleTools will send back the signon page in both cases, but by starting with the logout command you clear server resources from the previous script run. Your system administrators will thank you for this small act of kindness :-)

When playing back the script, I have a small problem; the script does not playback successfully. It tells me that it can't find a frame named "NAV".

The source of the problem is that Selenium does not quite understand the way that PeopleTools is doing it's navigation. When we click on the first navigation link from the Portal home page Selenium records the following two commands.

1. Command: clickAndWait, Target: link=(the name of the link)


2. Command: waitForPopup, Target: _parent, Value: 30000

After we leave the portal home page though, we are getting into PeopleTools generated HTML frames. The next command that Selenium IDE records is Command: selectFrame, Target: name=NAV. The NAV is the name that PeopleTools gives to the menu frame once we leave the portal home page. What we want at this point is for Selenium to wait for the NAV frame to load before we select it, but the commands that Selenium is generating are only waiting for our top level page to load.

Rather than run the entire test at a slower rate so that we're sure that the navigation frame is loaded, we'll insert an extra command before the selectFrame command that will tell Selenium to wait for that frame to load. To do that we

1. Right click on the selectFrame


2. Select "Insert New Command" from the popup menu


3. Type waitForFrameToLoad in the Command edit box


4. Type TargetContent in the Target edit box


5. Type 30000 in the Value edit box

One cool thing about Selenium IDE is that as you enter commands, you get type-ahead support for what commands are available. Once you select a command, then you get the help text for it automatically displayed at the bottom of the IDE window. Very nice! Here's a full list of all of the different commands that Selenium supports.

The other nice thing about the IDE is that we can copy and paste our waitForFrameToLoad command instead of typing it in everywhere. There are a few more places in our navigation script where the selectFrame command is used, so we'll paste it before each one. That allows us to run our script at full speed, but have it wait for the navigation to finish loading if the webserver is slow for some reason. Note that after we finish navigating we are then waiting for the frame called "TargetContent", so we use that name instead.

Skipping Navigation

In some cases you may want to include the navigation portion in your tests, but in many cases you'll want to just test a certain functional area. A good trick for doing this is just have Selenium go straight to the page that you want instead of navigating to it.

The open command in Selenium can be used in the middle of your test scripts, not just at the beginning, so we can replace all of the navigation commands with the open command and the value "/psc/ps/EMPLOYEE/PT_LOCAL/c/MAINTAIN_SECURITY.USERMAINT.GBL". Note that we used the psc servlet instead of the default psp. That will completely bypass the portal and just load the underlying component itself.

Making Assertions

Part of testing is making assertions about the behavior that is seen. Selenium supports making assertions about things as simple as text being on the page to whether specific cookies are present (a good way of checking that you are logged in is asserting that you have a PS_TOKEN cookie) and even as detailed as making assertions about the HTML source code that has been generated for a page.

There are somewhere in the neighborhood of around 100 different things that Selenium can make assertions about, so you should be able to come up with something that helps you validate the desired functional behavior that you are testing. For the example that we have been going through I added a the assertTextPresent command with the Target set to "Confirm Password" since that is the label for one of the fields on the User Profile page. This assertion will return true if "Confirm Password" is present anywhere on the entire page.

We can make some tighter assertions by narrowing the focus from the entire page to specific elements. The above assertion could also be implemented as the assertText, which takes an element locator in addition to the text that is being checked. We saw the use of element locators when working with the login form above; an element locator is just some way of identifying a single element on the page.

PeopleTools will typically generate unique IDs for each form field on page. These are normally the underlying record name and field name for the underlying value in the database (with row numbers if working with multiple rows). In the case of checking a label, PeopleTools will generate a "label" element, with the "for" attribute referencing which form field the label is for.

In this case, we end up with our element locator as //label[@for='PSUSRPRFL_WRK_OPERPSWDCONF'] because we want the label for the OPERPSWD_CONF field from the PSUSRPRFL_WRK record.



In the above screenshot we can see that our assertTextPresent assertion passed, but our assertText assertion failed. Selenium IDE provides the reason for the failure in the log though. The assertText assertion is making an exact check of the element's text, while the assertTextPresent assertion merely checks that the text exists at all across the entire page. Since PeopleTools is generating a colon at the end of the label, we would need to incorporate that in our assertion.

Saving Our Tests

Up to this point we haven't saved our test logic at all. In the Selenium IDE window, select File -> Save Test Case (or press Ctrl-S for a keyboard equivalent). You'll be prompted for a file name. I selected TestUserProfile.html. By default Selenium stores it's list of commands in a special HTML format, which is why we used that extension.

You can also have Selenium export a test case to various other programming languages (Java, C#, Perl, PHP, Python, and Ruby are all supported currently). The benefit to using a programming language for controlling Selenium is that you can then do things like have conditional logic, common subroutines, etc. The drawback is that you lose the ability to use Selenium IDE to work with them at that point. We'll stick with the plain HTML format for now while we're still getting familiar with Selenium, but future blog posts will get into using the programming language integration.



In the above screenshot you'll notice that I expanded out one section of the Selenium IDE window. That shows us the current test case being worked (TestUserProfile). If we click File -> New Test Case, we'll get an "Untitled" entry added in the list of test cases and an empty list of commands. We would then build up our test case just like we did above and save it.

Once you have a few test cases, then you can select File -> Save Test Suite to group the test cases together. You can copy and paste commands between different test cases, so if you find one test case is starting to cover too much functionality, you can break it into multiple test cases this way. Selenium lets you run either single test cases or run an entire test suite together, so you can break things in manageable chunks without losing the ability to group things appropriately.

I did notice a bug in the test case re-ordering within the Selenium IDE window though, so after you save your test suite, you'll probably want to open to the open the test file and re-order the tests listed there so they match the order that you want to run things in.

Wrapping Up

Now that we can start coming up with some meaningful tests, the next steps from here are to incorporate the execution of our tests into our Hudson environment so that they can be run automatically for us.

We'll also want to start integrating all of this with version control. We not only want to start keeping track of the different versions of our tests, but we also want to tie the execution of our tests to changes that are happening with the underlying PeopleSoft objects.

That way if a working test starts throwing assertion errors at some point, we'll be able to see exactly what changes were implemented in PeopleSoft that caused the problem, along with who did it and the underlying reason that the changes were implemented. And if necessary, revert those changes to put things back the way they should be.

Labels: 2009, Browser, Sysadmin, Testing, VersionControl

One of the reasons that we built out Grey Sparling Version Control for PeopleSoft on top of an industry standard version control tool (Subversion) instead of building our own proprietary repository is the sheer volume of other tools available that integrate with Subversion. There's a whole host of other reasons for using Subversion as well. If you'd like to learn more about Subversion you check out the presentation that we've given at OpenWorld and various other user conferences or go check out the Subversion website.

We're going to focus on a tool called Hudson. Hudson is an open source continuous integration server from Sun (so now it's from Oracle :-). A continuous integration server can do things for you like grab your latest source code, compile it (if necessary), run tests against it, and keep track of what happened.

We're not going to be compiling any code for this blog post though. We're just using Hudson for running tests against a PeopleSoft system. This first blog post is part of a new series of blog tests covering testing PeopleSoft. We're also have some upcoming webinars on these topics as well.

Installing Hudson

One of Hudson's strong points is it's ease of installation and setup. It's taken me longer to type this much of the blog post than it did to get Hudson up and running in a demo environment.

Head over to the main Hudson website and download the latest Hudson.war file. If you use IE it may get confused and save it with a .zip extension (both .war and .jar files are just .zip files that specific meaning for Java), so be sure to rename it as hudson.war once it's downloaded.

The only dependency that Hudson has is Java 5. You can type

java -version

at a command prompt to check which version you have. You then start Hudson running by typing

java -jar hudson.war

Hudson is very configurable, but we will accept defaults for now. You can change it later if you want. By default Hudson will create a directory called ".hudson" in your HOME directory when you launch it. This directory holds all of job definitions, output, logs, etc. Note that if you want to delete Hudson later for some reason just delete this directory and the hudson.war file.

Configuring Hudson

Now that you've started Hudson you can go to http://localhost:8080/ and you'll see something like this.



I created a user account before taking this screenshot, but by default Hudson will allow anonymous access (that's actually how I was able to create the user account), so don't run the initial setup on a non-trusted network.

Next we click the link that says "create new jobs". We called our job "Application Engine Test" since we're going to have it run an Application Engine program for us (keep the name reasonably short since it goes in a lot of URLs) and we selected "Freestyle Software Project". For our purposes of running tests against a PeopleSoft system we will always select "Freestyle Software Project" for our job type.



Now we get to the job configuration page. There's a lot of options here, but we'll skip over most of them to get started. Next to each input field is a "?" link that you can link to have inline help expand if you're curious about what the items do though.



The only thing that we changed in the first section was to add some descriptive text to our job. That will appear on the job home page. It can include HTML so you can do things like add links, styling, etc. It's not required, but it's a nice touch.



In the next section of the job configuration page is where we would specify where to pull things from version control. We'll save that for a future blog post, and just leave it as "None" for now.

This is also where we configure build steps for the job. Since we're running this on Windows, we choose Windows batch command. We won't cover it in this blog post, but Hudson can also run on Unix/Linux and have multiple instances of Hudson up and running together (technically there is one master instance of Hudson which can manage multiple "slave" instances).

The command line that put in for the job is

e:\pt849\bin\client\winx86\psae -CT ORACLE -CD PTSYS -CO PTDMO -CP PTDMO -R hudson -AI HUDSON_DEMO

A fairly standard command line for Application Engine. For now we have hard-coded the user/password, but those can be externalized. The -AI parameter is the name of the Application Engine program. We created a simple one called HUDSON_DEMO for the test.

That's good enough to try things out. Scroll to the bottom of the page and save the job. This will return you to the job home page.

Running Hudson Jobs



On the left side of the page are the various actions that you can take with the job. Click the "Build Now" link to run the job (the "Build" terminology comes from the fact that compiling or building software is one of the primary purposes of a continuous integration server).

You can't see it from the screenshots, but Hudson has some nice Ajax functionality that will update the page with what is happening as the build is running.



We can see in the Build History now that we have a successful build. Clicking on the link takes us to the build results.



The output shows "No Changes" because we haven't hooked this up with version control yet. Once that is done you would see a list of whatever program changes had taken place since the last build here. We also have the build timing information (19 seconds for it to start psae and run our program). We can also see the console output from the Application Engine program.



That "Hey, it worked" message is coming the PeopleCode that we put into the HUDSON_DEMO Application Engine program.



Pretty simple, but it lets us see that the environment is properly configured. Let's see what happens when we change the PeopleCode so that it fails. We'll just add an error statement in the PeopleCode to force it to fail. Then we run the Build again.



Now our job summary page shows that the job has failed. Let's look at the console output.



More normal error messages that you might see here are from SQL errors (for example someone altered a record definition that the App Engine program depends on, but didn't update the SQL). When we get into version control integration in the future, we'll see how to use the version control repository to help us figure out why something broke.

Let's spice up our job definition a bit. Here we kicked things off manually so we could tell that it failed, but we don't want to do things manually. Manual steps cost money! We want automation.

So go back into the job configuration page. In a previous screenshot we skipped over the "Build Triggers" section, but Hudson can automatically kick off builds in a variety of ways.

One way is by monitoring the version control repository for changes. If a check-in will cause some sort of breakage, then Hudson will pick it up right away, which is much better than after rolling something into production.

Another way is after other projects/jobs get built. We use this a lot within Grey Sparling. Once our tests run successfully, that kicks off other jobs that package things up for delivery.

Another way is to have Hudson run things on a schedule. This is a good way to catch any changes that you didn't realize that you were dependent on. Kick off everything once an hour or once a night or something just to be sure that nothing is broken.

You can also have external systems trigger Hudson builds if you need something else to control when builds should be run.

Once you have decided on which methods will trigger automated builds (you're not limited to just one method), then you decide on the post build notifications.



In this example, we have setup Hudson to send emails every time we have a problem with the build. If we kick off the build again, we'll see what this looks like.



The nice thing is that we get the output in the email so we can get some idea of the nature of the problem even through our Blackberries and iPhones :-)

If we fix up our test Application Engine program and run the Build again we'll get a single notification email that the build has returned to a successful state. By default you only get success emails when the build returns to a successful state after having problems; you won't get emails every time that a successful build occurs.



The link in the email goes to a permanent link for that build so it's easy to go back and review what happened months afterwards.



You'll also notice that we can start seeing trends in the Build History here. There's a few other views in Hudson that give us these high level "weather reports" (as Hudson calls them) that we'll get into in future blog posts.

Future

Hopefully you found this introduction to using Hudson for testing PeopleSoft useful. In future blog posts we'll cover more test automation topics such as:

• Having Hudson pull changes from version control into a pristine test environment before running the tests


• Running browser based tests via Hudson


• Integration with the newly released PS/Unit unit testing tool

If you have other topics that you would like to see covered, feel free to let us know; either via comments, email or join us on some of our upcoming webinars covering these areas.

Labels: 2009, Hudson, Testing, VersionControl

Continuing on in the cool stuff we've been working on series, I wanted to post something about a topic that goes way, way back.

Many years ago, Dave Yoder of Rainbird asked me at a DMUG user conference about how to get variable expansion support for file name references when building a project inside Application Designer.

Without having variables that you can expand, you always have to remember to change the name of the file that will be generated each time you build records/views/indexes, etc. It's really easy to forget and lose old copies. If you care about saving copies for yourself or for audit purposes, then it gets tiresome to always remember.

Here's some screenshots of what we have put together to address this particular issue. The first two screenshots show the Application Designer Build Settings dialog with the build log file set to c:\temp\%YEAR%\%MONTH%\%DAY%\PSBUILD_%DBNAME%.log. Here we are just changing the log file, but it works for any of the files that would get generated when doing builds in Application Designer.





The strings that are between percent signs (YEAR, MONTH, etc.) are variables that get expanded out to real values at the appropriate moment.

Here is what it looks like when you actually run the build.



As you can see, the generated log file has been created as c:\temp\2009\01\26\PSBUILD_PTSYS.log. Since today is January 26, 2009 and I was working in a PTSYS database, that's exactly what we expected :-)

There are also tokens for things like current hour, minute, second so if you like to do lots of builds in a short time frame you might want to take advantage of those as well.

In addition to things like date/time and connectivity info, there are also tokens that are supported by other Grey Sparling products.

For example, when you are using Grey Sparling Version Control for PeopleSoft you can also do things like reference which ticket number that you are currently working on. Here's the build settings showing the log file setting as c:\temp\Ticket-%TICKET%\PSBUILD_%DBNAME%.log



After running the build (note that our version control plugin is active now; it has to be to supply the current ticket number), you'll see that the build log file was generated as c:\temp\Ticket-4\PSBUILD_PTSYS.log. We could have included the date/time tokens as well if we had wanted to.



Now the build scripts, log files, etc. can easily be associated with the work that you are doing, and even automatically attached to the ticketing system if you want. That helps when your developers and DBAs need an audit trail of these sorts of activities. Fun to use and keeps the suits happy!

So if you run into Dave Yoder at a conference, be sure to thank him for coming up with the idea (and asking about it enough that it finally got built!)

Labels: 2009, ApplicationDesigner, Database, Products, VersionControl

Here's a quick little post on some cool stuff that we've been working on recently.

When you're accessing PeopleSoft via the web browser, it's pretty easy to see which environment that you are connected to - it's in the URL. But if you are using the client/server tools like PS/Query or Application Designer and have multiple sessions going, it can be hard to quickly tell them apart.

It would be nice if you could see what environment that you are connected to along with the current user ID directly in the title bar. Then you could see in the task bar (or in the window list when alt-tabbing) which session is which.



Which is exactly what we've done. If you take a close look at that title bar (click on the image for full size), you'll see that we have automatically prepended the current database name (HCM89) and the current user ID (PS) to the title bar.

Here's another picture of it in action when pressing Alt-Tab to cycle through the open windows. All of the Application Designer sessions now have good descriptive text in the title to be able to distinguish between environments.



This was done as part of our Version Control for PeopleSoft product. In addition to the current database and user ID, we also show which version control repository you are working with. If you look at the titles in the screenshots above you'll notice that some sessions are using a version control repository called "localdemo" (which is really just for experimenting/demoing) and some are using a version control repository called "gsdev", which is our production version control repository for Grey Sparling development. Definitely don't want to get those mixed up!

If you have an active ticket in the change request system that you are working on, we'll display that as well. In the screenshot below, I've selected ticket number 6 from the list of open tickets that are currently assigned to me and the title bar reflects that.



It's a not a huge feature, but it comes in very handy when you have multiple sessions going.

Update: here's what it looks with Windows XP "icon group combining".

Labels: 2009, ApplicationDesigner, Products, VersionControl

Back in the early days at PeopleSoft we used to ship software on floppy disks. A whole boatload of floppy disks. There was even this really cool floppy disk duplicator that we had where you would load in a stack of floppies, with the source in one stack, and blanks in the other. I think it could handle something like 50 disks at a time. Jay Hann would know for sure. Anytime the disk duplicator broke (basically whenever you looked at it), he was the one to get it going again.

Then this magical thing called a "CD" started getting popular enough that we could ship all of our software on 1 CD, and have room to spare. Wow! It wasn't quite as good as regular backup tapes, but still a huge leap forward.

A quaint blast from the past, eh? Well, I felt like I was transported back to that same era earlier today while looking at various escrow services out there (that's "escrow", as in code escrow, not escort services Mr. Spitzer). You see, we ship a lot of source with our applications, but we do have some parts that we do not ship the source to (and yes, just shipping all the source would make the question of code escrow go away). We had a customer ask about source escrow recently so we started looking into it.

The various escrow services all seem to be focused on the idea that once in a blue moon you will have a software release, send them physical copies of the software, and they will provide announcements that you have done so to the customers that you have deemed as beneficiaries. All this for several hundred dollars per customer per year.

Even worse, it doesn't appear that those entry level prices include much in the way of validating the code. A recent CIO magazine article about source code escrow mentions an incident with Radisson Hotels where they ended up having to get code out of escrow, but couldn't use it, because it was missing objects, etc.

The article does have several comments that complain that the authors should have mentioned that best practice is to "audit" the code escrow. But, none of the commenters, nor the escrow sites, has any good details about this audit would be performed. I'm sure that people with regular code escrow experience know a few tips and tricks about this, but I don't see too many of them blogging :-)

In a perfect world what would happen is that when we signed up, they'd give us a Subversion post-commit hook that we could use to mirror our version control commits to the escrow service. Then we'd give them the configuration for our Continuous Integration server (we use and love Hudson), so that the escrow service could run the same builds that we do. Heck, they could even use Hudson's email notification services to send the build logs and unit test results to customers as proof that they are actually receiving code and it is at least in semi-decent shape.

For the customer that then wants to do even more auditing, the escrow service could make the generated binaries available for the customer to test with. If those still work properly, then that's a pretty good sign that the escrow service is working properly.

The crazy thing is that this wouldn't be all that hard to do, or even that expensive. Maybe you wouldn't want to actually send all of your commits over, but it would be easy enough to limit what gets sent to release branches and not current development work.

The biggest challenges would be things like customer A is only entitled to version 1 plus maintenance releases, while customer B gets everything, etc. But figuring out those details is the value add that an escort (whoops - escrow!) service can provide. Most of the rest of it would just a bunch of hosted servers and some fairly standard configuration.

So will someone go build that so that we can toss out the CD burner. Please.

Labels: 2008, Business, VersionControl

Steve Chan has a link to an iSeminar from Cliff Godwin with some real meat about details on how the technical upgrade to Fusion is planned to work.

The screenshot from the presentation on Steve's website nearly made me spit out my drink though. The actual title of the tool is called "Upgrade Assistant for Fusion". One of the bullet points says "Leveraging the best ideas from PeopleSoft Change Assistant".

Don't get me wrong; the PeopleSoft Upgrade Assistant (which became Change Assistant after it learned how to deal with maintenance as well as upgrades) is a whole heck of a lot better than some of the old manual processes in PeopleSoft upgrades, but most PeopleSoft customers aren't huge fans of Change Assistant. Change Assistant has been around for awhile now¹, so a lot of folks have forgotten how much of an improvement that it really was.

In fact, when we first started Grey Sparling, we considered doing product packaging as Change Assistant Change Packages (A "Change Package" is essentially just a .zip file that obeys Change Assistant's structural conventions about what files/directories are in it; similar to the Java .jar file format), but we got a lot of pushback. Customers told us that they didn't use Change Assistant for anything beyond just standard PeopleSoft maintenance, and therefore didn't have it up and running in demo and test environments, which is typically where people install our evaluation versions.

What Change Assistant Needs

What does Change Assistant really need, even before Fusion? Two things.

One is to beef up the logic for dealing with large volumes of patches and fixes. There's one bug in particular that rears it's head regularly where there will be pauses of several minutes between each file being copied. I've seen this in action at customer sites and it came up as a question during one of the OpenWorld sessions as well. It's not a slow file copy; each file gets copied quickly. It's more like some sort of "don't swamp the network" logic swung the pendulum too far on the conservative side. People really hate this.

The other is a bit more focus on using Change Assistant as part of the regular customization process. Application Designer actually has support for PeopleSoft customers to create their own Change Packages when doing custom development, but it's not well documented or supported. This forces customers to require other procedures in place for moving customizations around (since even to this day, there are almost zero PeopleSoft shops that don't have any customizations). Since customers end up dealing with this, learning (and understanding; see item 1) Change Assistant is viewed as an extra cost.

In keeping with that second item of better integration with customer development processes, we here at Grey Sparling will have some Change Assistant integration for our version control product. Since we're already dealing with all of the pieces of a Change Package anyways (App Designer projects, SQRs, Crystals, etc.), it makes sense to go ahead and add knowledge of what a Change Package is to the product so that you can version your PeopleSoft Change Packages just like anything else and have that more deeply integrated into your development processes.

1) The number one hit on Google for "Change Assistant" is a link to the original Change Assistant Flash demo from back in early 2004. If you watch the actual demo and pay close attention you can actually see one of the demo environments labeled APOGONOS.

Andrew "Pogs" Pogonoski was the original product manager for a bunch of the work that went on to actually have PeopleSoft be able to deal with all of the Customer Connection integration and hosting the Web Services that provide Change Assistant with it's data. All of the actual demo that you see in the movie is him working away.

It's safe to say that without Pogs' diligence at the large amount of cat herding involved that Change Assistant never would have gotten off of the ground.

Labels: 2008, Fusion, Sysadmin, Upgrade, VersionControl