Monday 8 February 2010

Ultra quick Hudson setup to build a JDeveloper ADF application


At the UKOUG conference in 2008 I said that you could use cron, or windows scheduler, to schedule builds and tests, but this last year, at the same conference, I said that using cron to schedule builds and test runs really wasn't acceptable any more.



During a peer review of that presentation a colleague asked me why I'd changed my opinion in the last year, and I gave the ease of use, and ease of install, of Hudson as my answer. I may even have said that it was quicker than using cron, my bluff was called and my colleague asked for a demo as his team were still using cron to do all their test runs. Happily his team have now moved their infrastructure to Hudson so I'm assuming the demo went well.



Here is pretty much the demo I gave to him which shows :-

  1. Installing Hudson
  2. Configuring Hudson to have the right plugins
  3. Creating a new headless node to run builds
  4. Creating a new job that checked out and built a simple ADF application using OJDEPLOY

Installing Hudson


Download the latest and greatest hudson.war file from http://hudson-ci.org/ and save it to a sensible directory here I've chosen C:\hudson






I've also created a 'home' directory under the 'hudson' directory and set the HUDSON_HOME environment variable to that directory. This will tell hudson to store it's data and plugins into this directory. Since we know where it is it makes it easier later on to back this directory up. So we haver things prepared lets start Hudson using a unused port, 8989, in this example by passing the --httpPort=8765 argument when starting Hudson. As long as you have a version of Java greater than 1.5 setup the following will work.






Obviously redirecting the output of this command to a log would make more sense see the Hudson wiki for more details.


Configuring Hudson to have the right plugins



If you connect to the port you specified on your machine you'll see Hudson is now running






If you click on 'Manage Hudson' -> 'Manage Plugins' and pick the 'Installed' tab you can see we've already got some of the most popular plugins.
Note :- If your behind a proxy, as I am, the proxy setup is on the 'Advanced' tab on this page. You can then download any extra plugins you want, since we only need subversion for this quick example we'll just move on.





Creating a new headless node to run builds



Since one of the key features of Hudson is its ability to add extra nodes to spread the load of building and testing lets create a headless node that can build ADF applications.

If we head back to the 'Manage Hudson' page and click 'Manage Nodes' you can see we only have a 'Master' node, click the 'New Node' Link and we can start creating a new node.






I've given it a name that describes it's properties, i.e. that it won't have a display so it's 'headless', it's for build adf apps 'adf-build', and it's the first of it's kind so '1'. Now lets describe the node in full.






Since we want to build using OJDEPLOY lets tell Hudson where it is located on the node by creating a environment variable that points to it. OJDEPLOY is located in the jdeveloper\jdev\bin directory under the ORACLE_HOME in which you installed JDeveloper.






Save the node to register it with Hudson.






You can see that the node appears with a red cross as it isn't up and running. If you click on the node the information on how to start the slave is displayed. So lets copy the line displayed for launching a headless node, by downloading the slave.jar, which is a link in the text, and running the command.






Creating a new job that checks out and builds a simple ADF application using OJDEPLOY



Return to the Hudson homepage and click 'New Job'. Give the job a sensible name, since I'm building an HRApp, there had to be one this is related to Oracle, I'll mention that in the name, I'll also note that I'm building the trunk out of the Subversion repository. Finally the it will be a free style software project were building.






Enter a description for the job. Set a number of days to keep the build results, this is essentially to stop Hudson from becoming full of old archive data. Then tie the job to the headless node using the tag 'headless'.






Lets configure the source control portion next. I've pointed it to the URL I want to build, supplied credential information when prompted, and to keep this simple I'm going to checkout a clean copy of the Application each time and not use update.






We need to tell Hudson to Poll SCM every minute to see if the HEAD revision has changed, this is a quick operation under Subversion. We then describe the action to run when the build is triggered. I've just used a windows batch command here, although I usually use a shell as I spend most of my days developing on Linux



Here is the batch script in full, it removes any previous ear artifact, runs ojdeploy on the Application in the checked out working copy, copies the ear file to the root of the Hudson workspace, and removes the working copy.
del *.ear
%OJDEPLOY% -profile dgfud-app -workspace %WORKSPACE%\DGFUD\DGFUD-HRApp.jws
copy %WORKSPACE%\DGFUD\deploy\*.ear %WORKSPACE%
rmdir /S /Q %WORKSPACE%\DGFUD






I moved the .ear file generated to the root of the Hudson workspace so that we can archive it here.






A build will start immediately the job is saved as the trunk will always appear 'new' to Hudson the first time it looks. Wow, that was an epic description of a simple process. For further reading try Hudson Best Practices.

3 comments:

  1. You just saved me lot of (useless) work; I planned to figure out how to integrate Hudson with JDev this evening (and even planned to write a little blog about my results). Luckily is started reading my mails first, I got one of your Oracle wiki blog update and checked your blog... Nice article.

    It’s a small world we live in :-)

    Regards
    Gert

    ReplyDelete
  2. Hi GEOFF, thank you for your this page. My name is Dewi. I can`t speak english very well, so i save your understand.

    My question is Discard Old Builds`s option Days to keep builds. How many days setting in Days to keep builds 7days, 30days? And what it default days?

    Please tell me your answer. Thank you.

    ReplyDelete
    Replies
    1. There is no default.

      I'd recommend if you have space for it to keep 3 days of builds with 7 days of test results.

      If you have disk space do keep more but as long as you have a weekends worth you should be able to debug any issues.

      Delete

The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.