| Author |
Message
|
| fbaril3 |
 Posted: Tue Sep 10, 2002 6:04 am Post subject: VERSIONNING |
 |
|
Acolyte
Joined: 14 Jun 2002
Posts: 53
|
Hello,
 .....  !!!!!
I read IBM support pac called "change management and naming standard examples".
I saw that the name of
message flow
message sets
messages
were suffixed by a version number.
It seems to me a lot of versionning to take care for the developper with the Control Center.
The versionning for the exported files, message flow and message sets may be justified but is it really necessary to version the messages ? I mean if you modify a message content you may decide to change the version of your message set and not to version the message.
Could you tell me how you did implement versionning on your system ?
Does using 2 different versions (with different queues) of a message flow on a production env has got a sense ?
THANKS. |
|
| Back to top |
|
 |
| kirani |
| Posted: Tue Sep 10, 2002 8:16 am Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
The supportPac standards are good if you want to see all versions of message flows/Message Sets at once in the Control Center. I personally feel that there is too much to maintain here.
We generally have single version of Message Flow/Message Set into Configuration repository. After we reach logical conclusion of Message Flow/Message Set, we check-in exported file into Version Control System (ClearCase/VisualSourceSafe) and label the exported XML file appropriately. For some reason if you want to refer back to older version of message flow, we delete the existing copy of the message flow/message set and re-import the older one.
| fbaril3 wrote: |
Does using 2 different versions (with different queues) of a message flow on a production env has got a sense?
|
Depends on your requirement. Here is an example. You have Application A and Application B feeding messages to your message flow. Application B is migrated to newer version and hence there is a change in message format, but Application A still sends messages in older format. Now you need to have 2 versions of message flows in production, one for processing messages in older format, another one for processing messages in newer format.
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| fbaril3 |
| Posted: Wed Sep 11, 2002 1:04 am Post subject: |
|
|
Acolyte
Joined: 14 Jun 2002
Posts: 53
|
THANKS KIRAN for your answer.
I have a few more details to ask you :
when you say :
"We generally have single version of Message Flow/Message Set into Configuration repository. .."
Does this mean you only put the version number on the exported file and you don 't write it on the message sets and message flows in the control centers ?
Indeed, if you only change a message flow in the CC, it seems easier just to write the version number on the file. But in this case, how could I know the version which is in production ?
Please could you develop on this ?
THANKS ! |
|
| Back to top |
|
|
| kirani |
| Posted: Wed Sep 11, 2002 2:24 pm Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
Yes, we put version number only on the exported file when we check-in into ClearCase.
You could maintain version history of updates to the message flow in Description tab of the message flow. You could bring up this dialog box by selecting Properties from the pop-up menu when you right click in Message Flow pane.
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| marko |
| Posted: Thu Sep 26, 2002 12:48 pm Post subject: |
|
|
Apprentice
Joined: 28 Feb 2002
Posts: 27
|
| Though putting version history in the description of a flow does not tell you what version is currently deployed on a Broker. eg. What version is currently deployed to the production Broker? Without having a version as part of the flow name, is there any way of knowing what version is deployed? |
|
| Back to top |
|
|
| kirani |
| Posted: Thu Sep 26, 2002 3:10 pm Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
I guess your migration process should take care of this.
In a typical production environment, how would you find out what version of binary is running??
One would label all components for a particular Production Release, and compile them to generate the binary file. Binary file is then stored into version control system and labeled appropriately. By looking at version control system and Release notes I can find out what version of binary is running in production.
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| marko |
| Posted: Fri Sep 27, 2002 5:23 am Post subject: |
|
|
Apprentice
Joined: 28 Feb 2002
Posts: 27
|
As long as you have fool proof process, that is great. But it is very comforting to have some way of verifying what is deployed, without having to trust a human process.
In your example of a binary, the file name often includes a version number, or the binary has a runtime switch that will report version info (eg. -version), or the release notes are deployed with the binary, further providing version info.
What if an OS was designed such that it forced customers to document what versions of apps were installed on the user's machine, rather than the customer being able to query the machine for the currently installed versions? I doubt most people would find that acceptable. |
|
| Back to top |
|
|
| tchagan |
| Posted: Fri Sep 27, 2002 6:28 am Post subject: |
|
|
Apprentice
Joined: 10 Feb 2002
Posts: 31
|
The system we have implemented for our operators is that of adding a version number to the name of the base message flow (the one with the MQInput and MQOutput node).
In this case when we send a new version of a sub-flow to be deployed to live, the ops people take this flow, create a version of it in their versioning package (CVS etc.) then delete it from the repository, import the new one. Then when they wish to deploy they remove the base flow from the execution group assignment, rename the base flow with a new version number, assign it to an execution group then deploy. In this way when using the Operations tab you can visually verify that a new version has been deployed to the broker. It is not fool proof of course, you have to have strict standards in place in order to ensure that the deployed code is the correct code, but it is probably the only solution to actually seeing what has been deployed.
Terry |
|
| Back to top |
|
|
|
|
