Unzip the file to an installation directory, e.g. “/midvision” for linux or “C:\midvision” for windows.

This will create a directory called midvision. This location will now be referred to as $MV_HOME, e.g. “/midvision” for linux or “C:\midvision” for windows.

Edit the remote agent orchestration file.

If you plan to use a remote agent to run the deployments on the target servers then you will need to edit the remoting server file, putting in the host name of the server it will accept deployment requests from. Find the hostname of the machine you have installed the application to then type hostname from a command prompt.

e.g:

Goto $MV_HOME/remoting and edit the file midvision-remoting-server.xml. On line 43 change line:

<resource type=”auth.servers”>gui@localhost</resource>

To gui@hostname e.g.

<resource type=”auth.servers”>gui@user1-MV</resource>

Start the RapidDeploy Server

Goto $MV_HOME/bin and the run the start-up scripts to start the web app and the remote agent.

Wait until you see “INFO: Server startup in“ in the output logs of the tomcat console (which opens as a separate window in Windows environments), alternatively check the $MV_HOME/logs/rapiddeploy-web-app.log for the line ”RapidDeploy web application is started” and ensure there are no errors, then go to http://localhost:9090/MidVision in a web browser. (Replace localhost with your linux server hostname/IP as appropriate)

At the login page enter the default username “mvadmin” and the default password “mvadmin” then click “Login”.  You will then be presented with a license page. Request a trial license from MidVision by emailing licensing@midvision.com. Once you have been emailed the license, enter the values on the screen and accept the EULA.

Note: This demo uses a Hypersonic in-memory database. This means if the web application process is killed from the Task Manager or a “kill” command then all data will be lost. To ensure that your data is stored to a file when the application is stopped, run the “stop-web-app.sh” or “stop-web-app.bat” script which is in the $MV_HOME/bin directory.

Create the WMQ Binary Installation Package

You will need to take your latest version of your WMQ Binaries and need to package this up so that RapidDeploy can make use of it.

If you want to just focus on RapidDeploy’s WMQ Configuration Deployment capabilities then just skip this step and ensure you are running on a server with WMQ installed.

WMQ Binary Package for Windows

Here is an example of what to do to package up the WMQ Binaries for v7.0.1.3 for Windows:

• Download / copy over the WMQ Binary Files
• Now create a new jar file wmq-binary-7013.zip (i.e. wmq-binary plus the version number)
• At the root of this file, create a windows directory
• Create a windows/install_WMQ_7.0.1.3 directory
• Unpack the WMQ Binary files to the install_WMQ_7.0.1.3 directory
• Now, create the listfile  windows/install_listfile.txt  with the following contents (this tells RapidDeploy what to execute):

install_WMQ_7.0.1.3\Prereqs\IES\MSI\IBM WebSphere Eclipse Platform V3.3.msi responseFile=Response_Eclipse.ini
install_WMQ_7.0.1.3\MSI\IBM WebSphere MQ.msi responseFile=Response_WMQ_7013.ini

• Now, create the response file windows/Response_Eclipse.ini as follows (to tell the WMQ installer what options to install for eclipse):

  ;
  ;**********************************************************
  ; Response stanza: Required.
  ;
  [Response]
  ;
  ;**********************************************************
  ; USERCHOICE property: Optional; ignored if installation is silent (non-interactive).
  ; Value "0": During the interactive installation, the user cannot review
  ; and change the values set by this response file.
  ; Any other value: The user can change these settings.
  ;
  USERCHOICE="yes"
  ;
  ;**********************************************************
  ; Feature properties: Optional.
  ; Format: ADDLOCAL="FeatureName,FeatureName"
  ;         REMOVE="FeatureName,FeatureName"
  ; Keywords and values entered here determine what gets installed or uninstalled.
  ;
  ADDLOCAL="Server,Explorer,JavaMsg,Toolkit"
  REMOVE=""
  ;
  ;**********************************************************
  ; KEEPQMDATA property: Optional.
  ; Value: "delete", If uninstalling the Server feature, delete any
  ; queue manager data.
  ; Any other value: If uninstalling the Server feature, keep any
  ; queue manager data (default).
  ;
  KEEPQMDATA="keep"
  ;
  ;**********************************************************
  ; KEEPWEBDATA property: Optional.
  ; Value: "delete", If uninstalling the Web Administration Server feature, delete any
  ; web administration scripts.
  ; Any other value: If uninstalling the Web Administration Server feature, keep any
  ; web administration scripts (default).
  ;
  KEEPWEBDATA="keep"
  ;

• Now, create the response file windows/Response_WMQ_7013.ini WMQ as follows (to tell the WMQ installer what options to install):

; Response stanza: Required.
;
[Response]
TRANSFORMS="1033.mst"
AGREETOLICENSE="yes"
;**********************************************************
; USERCHOICE property: Optional; ignored if installation is silent (non-interactive).
; Value "0": During the interactive installation, the user cannot review
; and change the values set by this response file.
; Any other value: The user can change these settings.
;
USERCHOICE="yes"
;
;**********************************************************
; Feature properties: Optional.
; Format: ADDLOCAL="FeatureName,FeatureName"
;         REMOVE="FeatureName,FeatureName"
; Keywords and values entered here determine what gets installed or uninstalled.
;
ADDLOCAL="Server,Explorer,JavaMsg,Toolkit"
;REMOVE=""
;
;**********************************************************
; KEEPQMDATA property: Optional.
; Value: "delete", If uninstalling the Server feature, delete any
; queue manager data.
; Any other value: If uninstalling the Server feature, keep any
; queue manager data (default).
;
KEEPQMDATA="keep"
;
;**********************************************************
; KEEPWEBDATA property: Optional.
; Value: "delete", If uninstalling the Web Administration Server feature, delete any
; web administration scripts.
; Any other value: If uninstalling the Web Administration Server feature, keep any
; web administration scripts (default).
;
KEEPWEBDATA="keep"
;

After the above setup your package should look like this:

This package should be copied over to the $MV_HOME/buildstore directory.

WMQ Binary Package for Linux

Here is an example of what to do to package up the WMQ Binaries for v7.0.1.3 for Linux:

• Download / copy over the WMQ Binary Files
• Now create a new jar file wmq-binary-7013.zip (i.e. wmq-binary plus the version number)
• At the root of this file, create a linux directory
• Create an linux/7013 directory
• Create an linux/update_7013 directory
• Unpack the WMQ Linux Binary files to the 7013 directory
• Cut the files gsk7bas-7.0-4.27.i386.rpm and gsk7bas64-7.0-4.27.x86_64.rpm (the gsk packages) and put them in the update_7013 (RapidDeploy will do an rpm update for the GSK Toolkit, not an install – as required)
• Now, create the listfile  linux/listfile.txt  with the following contents (this tells RapidDeploy what linux RPM packages to install):

update_7013/gsk7bas64-7.0-4.27.x86_64.rpm
update_7013/gsk7bas-7.0-4.27.i386.rpm
7013/MQSeriesServer-7.0.1-3.x86_64.rpm
7013/MQSeriesTXClient-7.0.1-3.x86_64.rpm
7013/MQSeriesClient-7.0.1-3.x86_64.rpm
7013/MQSeriesConfig-7.0.1-3.x86_64.rpm
7013/MQSeriesEclipseSDK33-7.0.1-3.x86_64.rpm
7013/MQSeriesJava-7.0.1-3.x86_64.rpm
7013/MQSeriesJRE-7.0.1-3.x86_64.rpm
7013/MQSeriesKeyMan-7.0.1-3.x86_64.rpm
7013/MQSeriesMan-7.0.1-3.x86_64.rpm
7013/MQSeriesMsg_cs-7.0.1-3.x86_64.rpm
7013/MQSeriesMsg_de-7.0.1-3.x86_64.rpm
7013/MQSeriesMsg_fr-7.0.1-3.x86_64.rpm
7013/MQSeriesMsg_es-7.0.1-3.x86_64.rpm
7013/MQSeriesMsg_hu-7.0.1-3.x86_64.rpm
7013/MQSeriesMsg_it-7.0.1-3.x86_64.rpm
7013/MQSeriesMsg_ja-7.0.1-3.x86_64.rpm
7013/MQSeriesMsg_ko-7.0.1-3.x86_64.rpm
7013/MQSeriesMsg_pl-7.0.1-3.x86_64.rpm
7013/MQSeriesMsg_pt-7.0.1-3.x86_64.rpm
7013/MQSeriesMsg_ru-7.0.1-3.x86_64.rpm
7013/MQSeriesMsg_Zh_CN-7.0.1-3.x86_64.rpm
7013/MQSeriesMsg_Zh_TW-7.0.1-3.x86_64.rpm
7013/MQSeriesRuntime-7.0.1-3.x86_64.rpm
7013/MQSeriesSamples-7.0.1-3.x86_64.rpm
7013/MQSeriesSDK-7.0.1-3.x86_64.rpm

After the above setup your package should look like this:

• wmq-binary-7.0.1.3.zip
• Linux (directory)
• listfile.txt
• 7013 (directory)
• MQSeriesServer-7.0.1-3.x86_64.rpm
• MQSeriesRuntime-7.0.1-3.x86_64.rpm
• .
• .
• update_7013 (directory)
• gsk7bas64-7.0-4.27.x86_64.rpm
• .

This package should be copied over to the $MV_HOME/buildstore directory.

Download and Install the WMQ Example App Plugin

Ensure the web application is started. Go to “Help / Plugin Manager” the “Available Plugins / Patches” tab. Click the “Install” button on the “WMQ Example App” Plugin and then “Yes” to confirm, the project files will be downloaded to the $MV_HOME/projects directory. Once the download is complete the plugin will appear in the “Installed Plugins / Patches” tab.

Installed Plugins (Click to Enlarge)

Alternatively, download the latest zip file from http://www.midvision.co.uk/wordpress/dnld/plugins/demo_projects_310/rapiddeploy-demo-projects-3.1.0-websphere-mq.zip

Download and install the Websphere MQ Extension plugin

Ensure the web application is started. Go to “Help / Plugin Manager” the “Available Plugins / Patches” tab. Click the “Install” button on the “WMQ Extension” plugin.  This will install the extension to midvision’s lib directory: this is the code that enables RapidDeploy to be able to install, patch and configure to WMQ targets.

Start the Remoting Agent

Goto $MV_HOME/bin and the run the start-up scripts to start the web app and the remote agent.

A new windows should be launched.  If the remoting agent starts successfully you should see the message ‘Agent has been started, now listening.‘

In the  real world example the agents would be installed on all the target WMQ servers we install to and they would mediate deployments from the RapidDeploy Server to the target Servers (SSH could also be used instead).

Configure the Resources in RapidDeploy (only for RapidDeploy 3.1)

NOTE: If you are using RapidDeploy 3.2 then you no longer need to create these projects as the Plugin Installation process automatically creates the projects and metadata within RapidDeploy – please skip this section.

Please note. If you are running RapidDeploy against an oracle database, a Sql script can be found in $MV_HOME/plugins/WMQ Example App/<VERSION> that will create all of the following resources for you. You will still need to edit each project and replace “MV_HOME” with the correct path to the RapidDeploy install directory, and run a discovery on each project by editing it and then clicking “Discover” and clicking “Ok” to confirm.

Create the Projects

Go to “Resources/Projects/Add Project” then enter the following information (remember to change $MV_HOME with the actual location).

WMQ Binary Install Project (Click to Enlarge)

Then click “Create”. Now add another project.

Then click “Save”.

WMQ Deployment Project (Click to Enlarge)

Now edit the project named WMQ_DEPLOY and then click “Discover” and click “Ok” to confirm.

This will search the project configuration directory and look for the environment definition files and create any servers, environment, instances and deployment components it finds in to the application database. The environments are defined by the file names defined in the project properties directory. The structure of the environment filename is this:

SERVER.ENVIRONMENT.INSTANCE.APPLICATION

As the project WMQ_DEPLOY has a pre-configured environment definition, the discovery will create a new server named “wmqdemosvr01”, a new environment named “env-wmq-demo” (the Queue Manager Name) and a new instance named “DEMO”.

We will later configure the connection details to the server so we can install WMQ to that server and also we will configure the environment connection details to enable us to connect to the Queue Manager when taking a snapshot after deployment.

This environment is to form our ‘Golden Configuration’.  This will form the basis of all other Queue Managers which are built to the same specification: they will all use this single set of mqsc artefacts, and only the configuration information will change to alter connection details and environment-specific properties.

Orchestration Panel

It is worth looking at the project orchestration panel at this point. The Examples projects have preconfigured orchestrations, but these may be amended as desired to add or change individual task actions (from the list of around 150 on the left hand side) for this deployment. In the example below, the TOKENIZERS tree item is opened, displaying three tasks. Task actions are environment independent actions that run in sequence whenever this deployment project is run (when any deployment package based on this project is deployed).

Take a look at the orchestrations for the other projects.

Orchestration Panel for the WMQ_DEPLOY Project (Click to Enlarge)

Configure the Server

Goto “Resources/Targets/Servers” then edit the server named localhost. Edit these fields (remember to change $MV_HOME with the actual location, you will also need to ensure the Build Store directory exists on your target):

Then click “Save”.

Click edit on the server named “localhost” and then click “Test Agent” and click “Yes” to confirm. The application will then check it can communicate with the remote agent. You should see the following output:


Test Success
The test connection completed successfully.


If the test was successful.

Configure the WMQ Installation Directory

In this section we define the file path that WMQ will be installed into on the target server: the installation directory is not used as you cannot change the target directory in WMQ v7 and below, but will be used for later versions.

Go to “Resources / Targets / Installations” then click “Add Environment Installation”.

Then click “Create”.

Now, go back into Resources / Targets / Installations, and then on the installation you have just created, click the edit button.

This will present you with the environment variables for this installation: click “New Property” and add the following key/value pairs (once you have entered the value for one click on Save, and then do the same again for the other – leave the encrypted box unchecked):

For Windows:

For UNIX: No key/value pairs are required. It will install the correct package by default.

Create a deployment package

Goto “Resources/Software Management/Packages” then select the WMQ_DEPLOY_DEMO project from the drop down.

Click “Add Package Wizard” button and enter “WMQ_DEPLOY_DEMO” as the package name. Check the “Skip to Finish” checkbox and click next.

Click “Create This Deployment Package” on the final tab.

We have now packaged our project directory, including an mqsc file and all the required configuration to create the target Queue Manager. This package can be used to create our environment. It could also be used to create additional environments by simply cloning the configuration of the first environment – we will be doing this later on.

Install WMQ

Disable UAC if Installing on Windows

If you are using RapidDeploy to install WMQ on Windows you must disable User Account Control (UAC).  This can be done a number of ways, via User Account Control Settings, Group Policy or by changing the registry (the former is probably the best way).  Please see the link below:

http://www.petri.co.il/disable-uac-in-windows-7.htm

Ensure c:\temp exists

The installation saves the log file information for wmq into c:\temp.  Please create this directory if it doesn’t already exist.

Execute Binary Install Job

If WMQ is already installed then go to the next section.  If not, go to “Jobs / New Job” then select the project WMQ_BINARY_INSTALL and select ‘EnvironmentInstallation: /opt/mqm’. Click Next – you should see that your wmq-binary-7.0.1.3 package should be automatically selected (or whatever version you packaged up).

Select ‘Skip to Finish’ -> click Next.  Click on Execute Request -> Yes.  Now wait for the install to complete – check Executing Jobs / Previous Jobs.

Once complete WMQ will be installed on your machine.  To confirm this is the case open up a new command window and issue the following command:

dspmqver

This should work and MQ should tell you what version is installed on your machine e.g.

Name:        WebSphere MQ
Version:     7.0.1.3
CMVC level:  p701-103-100818
BuildType:   IKAP - (Production)

Restart Remoting Agent and RapidDeploy Server

Because we have just installed MQ we must restart the agent and the application so they know about the new MQ installation and updated environment variables.

In order to do this, kill the remoting agent window (either via the task manager or by pressing the x button on the top right hand side of the remoting agent command window).  For unix, type stop-remoting-server.sh

In a command line window, to stop the application, go into $MV_HOME/bin and type stop-web-app.bat (or .sh).

Now restart the agent by going to $MV_HOME/bin and then run start-remoting-server.bat (or .sh).  Restart the server by typing start-web-app.bat (or .sh).

Create and Deploy to an Example Queue Manager

The following steps will:

• Create a Queue Manager and start it
• Create and start a listener
• Create a Server Connection Channel
• Deploy some sample MQ Configuration to that Queue Manager

Deploy the Package.

Go to “Jobs / New Job” then select the project WMQ_DEPLOY_DEMO then open the server, environment, instance and select the application “demo_app” then click “Next”.

Now select the version, which is the deployment package you have just created, select “Skip to finish” then click “Next”. Click “Execute Request” then click “Yes” to confirm. This will start to deploy the package.

Once the job has completed you can view the deployment log file from the Previous Jobs section.

Check the Deployment

Open up MQ Explorer and you will observe that you have a Queue Manager created called QMAPRD01, which contains a number of non-default objects.  Alternatively, on the command line run the following:

• runmqsc QMAPRD01
• dis ql(*)
• dis chl(*)

Snapshot a Queue Manager

Now WMQ has been installed we can take a snapshot of the default configuration to use as a control when configuration changes are made.

Configure the Instance (only required for RapidDeploy 3.1)

This is already done by the plugin installer for RapidDeploy 3.2 onwards.  If using 3.1, go to “Resources / Targets / Instances” edit the instance named “DEMO”. Enter the following values:

Then click save.

Take a Queue Manager Snapshot

Now we will take a snapshot of the WMQ Configuration that has just been deployed. It is a “Golden Image” version of the configuration, which will be used to compare against in the future.

Go to “Resources / Targets / Instances” edit the environment named “DEMO“. Then click “Snapshot” then click “Yes” to confirm. The snapshot will be requested. You can go to “Jobs / Executing Jobs” and see the log output of the snapshot.

Explore the snapshot

If you check the snapshots directory $MV_HOME/snapshots, you will see a new snapshot file (it is also stored in the application database).

If you open the file in an editor, you will see that the snapshot contains the connection details of the snapshotted Queue Manager as tokens in the header, and also all references to the Queue Manager name are tokenised throughout the file.  This will prove invaluable later on in this exercise when we use this snapshot to create a deployment target and then is cloned to a new environment.

Make a manual change to the Queue Manager Configuration

Connect to the QMAPRD01 Queue Manager and make some manual changes: e.g. alter the connection string of the sender channel.

Now take another snapshot as was done in the previous section.

Compare The Snapshots

Go to “Environment / Environment Comparison”, click on “Snapshot Comparison”.  Enter “5” into the “Comparison Context size (optional 1-50):” field.  This will display 5 lines above each difference and 5 line below, to give the comparison some context.  If you leave this field blank it will display the complete XML, which can be quite large.  Then select snapshot with ID 2 for the left side and snapshot with ID 1 for the right side, then click “Compare”.

You should see the differences between the original configuration and the current configuration highlighted.

Create a new Golden Environment in RapidDeploy

Now that we have a production environment which we are happy with, we can turn that into a golden template for creating as many new environments as we need. We can then keep these environments (typically our “Route To Live” environments) in sync throughout the lifecycle of our project, deploying new versions of code, configuration or both. We can always roll back to our Golden Image, or any subsequent change made upon it, by redeploying previous deployment packages.

We will now create a new Golden Environment, point it at Production, snapshot and template that to form a complete environment from which we can clone all future Queue Manager instances.

Click on Environments -> Edit/Promote -> Select WMQ_DEPLOY_DEMO project.  Click on the ‘New Environment’ button.

Now enter values as show in this screenshot:

Server: wmqdemosvr01, Environment: env-wmq-gold, Instance: QMAGLD01, Application: airline-reservations

Click on the ‘Create’ button to create this new environment.

Point Golden Environment at our existing Production Queue Manager and Snapshot

Now we have created our golden Queue Manager definitions, we have to point it at the Production Queue Manager and take a snapshot.

Click on Resources -> Targets -> Instances.  You will see a list of instances.  Click on the edit button (the ‘i’ button) of QMAGLD01, to edit the instance.

On the General Tab set the software version to 7.0.  Now click on the Connectivity Tab. The first field should be the WMQ Connection details to QMAPRD01 (as we are going to snapshot that QM and use it to create our golden environment), like so:

QMAPRD01:localhost:1414:SYSTEM.DEF.SVRCONN

Also, clear out the password field, and then click on Save -> Yes.

Now take a snapshot by editing the QMAGLD01 instance and pressing the snapshot button (as can be seen above).  Check the previous jobs to ensure the snapshot worked.

Create further environment definitions from the one created

Convert Snapshot to Template

Go to Environment -> Edit/Promote. Select the WMQ_DEPLOY_DEMO project.

Click “Create Template from Snapshot Wizard”. We are going to template the new environment we have just created.

On the “Choose Location” tab, accept the default (this projects configuration directory). You can change this value if you want to use the configuration from this project to “seed” another project.

Click “Next”

On the “Snapshot Selection” tab, select one of the snapshots you took above. It doesn’t matter which one.

Click “Next”

On the “Name” panel you need to give the new environment you are creating a name, based on the server, environment instance and application you are going to deploy to.

Some values may be prefilled with the values from the originating environment (where the snaposhot was taken from). Add additional values. In this case we want to just template the development environment as our golden environment.  Leave the server as it is, set the environment to env-wmq-gold and instance to QMAGLD01  and set the application to ”airline-reservations“.

Click “Next”

On this panel we convert the snapshot to a template by adding placeholder variables to the snapshot, which are replaced at deploy time to environment specific values.

In this case download the file, and in a text editor look for the string (@@QMGR_NAME@@.QMNEWYRK).  This is the sender channel: change the connection name for this channel to be a token i.e. where it is currently a fixed string:

CONNAME(‘newserver.co.uk(1414)’)

 change it to:

CONNAME(‘@@NEWYRK_HOST@@(@@NEWYRK_PORT@@)’)

Also, find the following:

PORT(1420)

and replace it with:

@@QMGR_PORT@@

Normally you would repeat this for all the variables you want to change. But for this demo we’ll just change these ones.

Click “Next”.

If you go back to the snapshot, you will see as well as the tokens for the NEWYORK queue manager connection details, the snapshot automatically adds in tokens as comments at the top.  At a later stage these tokens will be applied to the .wmq connection details so that when we change these tokens we will automatically deploy to a different queue manager.

Now fill in the values for these tokens as appropriate, as per the screenshot below. Note as this is our golden environment we are just setting dummy token values as we will never deploy this but use it as our foundation for all other Queue Managers within this project.

Click “Next”

On the final tab click “Create this environment”. The template files will be copied to the project, and the configuration and dictionary files created.

Clone Gold to Dev01

We are now going to take our golden environment and clone it to create our production environment.

Go to environment / Edit/Promote, and choose your WMQ_DEPLOY_DEMO project from the picklist.

Now click the last button  on the right of the golden environment – when you hover over it the tooltip will inform you “Clone logical environment”.

You will be presented with a number of fields allowing you to change the server, environment, instance and application for this cloned environment (and you change at least one to create a new unique deployment target).

Change the environment and instance to reflect the new environment: env-wmq-dev01 and QMADEV01.

Now click “Next”, and then click “Next” on the configuration Directory tab, as we want this new development Queue Manager to be in the same project.

Now click “Next”.  You will now be presented with all the tokens that were previously exposed when you last templated the golden environment.  This consists of the auto-tokenised connection details of the target Queue Manager (i.e. @@QMGR_NAME@@, @@QMGR_HOST@@, @@QMGR_PORT@@, @@QMGR_CHANNEL@@) as well as the ones we added for the point to point connection to our New York Queue Manager.

Change these values to the desired new values – you would definitely change the details which determine the target Queue Manager to deploy to, and that Queue Manager may well talk to a different New York Queue Manager.  We are going to create our first dev environment as follows:

Create a new package again

We now need to create a new package which contains our new development deployment target.  Goto “Resources/Software Management/Packages” then select the WMQ_DEPLOY project from the drop down.

Click “Add Package Wizard” button and enter “WMQ_DEPLOY_DEMO_002″ as the package name. Check the “Skip to Finish” checkbox and click next.

Click “Create This Deployment Package” on the final tab.

Deploy to our new Development Environment

Now we have create our development environment we can go ahead and deploy to our new environment with our latest package:

You should now see that you have a new Development Queue Manager QMADEV01 built to the same pattern as QMAGLD01, listening on port 1430, with it’s own channels  to New York Queue Manager on a different host and port.

For example, you will see that the channels QMADEV01.QMNEWYRK and QMNEWYRK.QMADEV01 have automatically been created as all references to the golden environment Queue Manager name where tokenised in the original snapshot.  In our production environment these tokens have been replaced with the new Queue Manager name throughout, as well as those tokens we explicitly defined during template creation (i.e. sender channel connection details).

Result

We have used snapshot/template/promote to create our Golden Environment from our production environment.  We have then created our development environment from it based on generic artefacts from our golden configuration, but with configuration information specific to this environment.

We have demonstrated creating a single golden configuration which can then be used to deploy out to all Queue Managers for that project, across the development lifecycle (i.e. from development, into test, UAT and Production).  In each environment we only have to change the tokens that we have exposed from the original snapshot to change the target Queue Manager and the salient properties that change between Queue Managers (e.g. sender channel details etc.)

 Loading ...