Version 11
Created by objectiser on Mar 26, 2010 12:21 PM. Last modified by objectiser on Jan 20, 2011 10:58 AM.

    This article outlines the release steps that should be followed when releasing a version of RiftSaw.

     

    Tag the source code and upload artifacts into maven repo

     

    Release process of RiftSaw

     

    Obtain and Verify the Binary Distribution

     

    In the days prior to a new release, the release should be labelled with the appropriate release version, and the RiftSaw hudson job(s) should be used to build a candidate distribution of the release.

     

    When a successful Hudson build has been completed, the binary distribution should be downloaded.

     

    Unpack the binary distribution into a suitable folder and check for the presence of the following:

     

    • bin - top level folder containing two commands, bpelc and sendsoap
    • db - top level folder containing configuration information to support various databases
    • docs - top level folder containing a 'getting started guide' and 'user guide'  
      • check that the html and pdf versions are available
      • check that the version within the documents are correct
    • install - installation folder
    • lib - various jars required for the samples
    • modules - the components to be deployed to the app server
    • samples - contains four sub-folders, common, esb, quickstart and tutorial  
      • check that each example has a readme.txt
    • top level files - JBossORG-EULA.txt and ReleaseNotes.txt  
      • check that the release notes relate to the pending release

     

     

    Setup Environment

     

    First step is to setup a fresh server environment as identified in the installation section of the Getting Started Guide.

     

    Once the server has been installed, and configured with any additional modules (e.g. updated web service stack), then follow the installation instructions in the Getting Started Guide to deploy RiftSaw into the server.

     

    Start up the server, and check the server.log to ensure that there are no errors/exceptions.

     

     

    Testing the Release

     

    Samples

     

    Work through all of the samples, including quickstarts, esb and tutorials, to check that all of them work correctly.

     

    When checking an example:

     

    • Check that the readme.txt exists and that the contents make sense
    • Try the samples as described in the instructions
    • Check that the project can be loaded into Eclipse
      • Exceptions to this are the simple_invoke and bpel_event_listener quickstarts, as these projects either don't deploy a BPEL process, or involve more components that need to be deployed along with the BPEL process

     

     

    Commands

     

    The commands in the bin folder should be tested.

     

    The bpelc can be tested using the following commnd:

     

         ./bpelc ../samples/quickstart/hello_world/bpelContent/HelloWorld.bpel

     

     

    The sendsoap command can be tested using the following command:

     

         ./sendsoap http://localhost:8080/Quickstart_bpel_hello_worldWS ../samples/quickstart/hello_world/messages/hello_request1.xml

     

    (This assumes that the hello_world quickstart sample has previously been deployed, and the server is currently running).

     

    Versioning

     

    Deploy the simple_correlation quickstart example. Version 1 should be used, so this is using the default deploy command ant deploy.

     

    Once deployed, follow these steps:

     

    • Send the first message using ant sendhello
    • Edit the BPEL process in the bpelContent folder, so that the string literal part of the goodbye message is changed
    • Re-deploy the example using the command ant deploy -Dversion=2 - note, do not undeploy the previous version
    • Send a second hello message, using ant sendhello2
    • Send a goodbye message, using ant sendgoodbye2
      • check that the goodbye response has the modified text from the updated BPEL process
    • Finally, send the goodbye message, using ant sendgoodbye
      • check that the goodbye response has the text from the original (unmodified) BPEL process

     

    Next step is to check that if the older version was re-activated, that new requests will correctly be handled by the re-activated process. This can be tested by:

     

    • Start the BPEL console
    • Select the 'Runtime' tab on the left panel, and select 'Deployments'
    • You should see two entries, one for each version. Select the top greyed out line, representing version 1, and press the 'Activate' button on the bottom right of the console.
    • After acknowledging that the older version should be re-activated, then the top line should be re-enabled, and the second version retired.
    • At this point, send a third message using ant sendhello3
      • check that the hello response is correct according to the original (unmodified) BPEL process
    • Finally, send the goodbye message, using ant sendgoodbye3
      • check that the goodbye response is correct according to the original (unmodified) BPEL process

     

     

    BPM Console

     

    When the server has been started, and some sample processes have been deployed, login to the console to check that the appropriate process definitions (and versions) are present.

     

    Deploy a second version of the same process definition, and refresh the console to ensure that it becomes visible.

     

    Using the 'simple_correlation' quickstart example, deploy version 1. Then work through the following instructions:

     

    • Send the first 'hello' message using ant sendhello
    • Refresh the console to check that a process instance exists under the 'HelloGoodbye' process 
      • Select the process instance
      • The 'Show Instance Data' button should become enabled
      • Select the button, this should display a window with variable information
    • Send the first 'goodbye' message using ant sendgoodbye
    • Refresh the console to check that the process instance is no longer present
    • Send the second 'hello' message using ant sendhello2
    • Refresh the console, but this time select the process instance and press the 'terminate' button
    • Send the second 'goodbye' message using ant sendgoodbye2
    • This command should timeout, as this goodbye message does not match to an existing active process instance

     

     

     

     

    JBoss Tools

     

    Setup a JBoss Tools environment within a suitable version of Eclipse. Create a server runtime configuration that references the previously configured JBossAS environment.

     

    Load the samples into the Eclipse environment.

     

    Start the server runtime from within the Eclipse environment.

     

    Deploy a selection of the samples, one at a time, and issue the test messages (using the ant script or soapui).

     

     

    Obtain and Verify the Source Distribution

     

    When a successful Hudson build has been completed, the source distribution should be downloaded.

     

    Unpack the source distribution into a suitable folder and check for the presence of the README.txt in the top level folder. Read the instructions in this file and build the release.

     

    If the source distribution correctly builds a binary and source distribution in the distribution/target folder, then the source distribution has been verified.

     

     

    Uploading Documentation and Source/Binary Distribution

     

    When the release has been tested, and is ready to be uploaded to the RiftSaw website, then follow these instructions to perform this step.

     

    Then all that remains is to announce the release on the RiftSaw blog and user/dev forums!