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.
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
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.
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:pt849binclientwinx86psae -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 Eng ine 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.
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:
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