| Author |
Message
|
| fitzcaraldo |
 Posted: Sun Feb 12, 2012 11:59 pm Post subject: Size of running flows |
 |
|
Voyager
Joined: 05 May 2003
Posts: 98
|
Environment WMB V6.x on AIX
I have inherited a poorly managed WMB environment with no reliable records as to what version of each flow is running in production. There is a CVS repository but also additional code that is not in CVS.
I want to know what version of each flow is running but there is no attached metadata. Failing all else, is it possible to determine the size of a .cmf deployed in a given environment and compare that with each candidate version after adding to a bar?
If not - any other ideas? |
|
| Back to top |
|
 |
| marko.pitkanen |
| Posted: Mon Feb 13, 2012 12:58 am Post subject: |
|
|
Chevalier
Joined: 23 Jul 2008
Posts: 440
Location: Jamsa, Finland
|
Hi,
You should be able to fetch for example with Configuration Manager Proxy API the information when and from what broker archive resources have been deployed.
And if you are in really deep troubles you can get more detailed information about deployed message flows with mqsireportproperties command.
--
Marko |
|
| Back to top |
|
|
| adubya |
| Posted: Mon Feb 13, 2012 1:14 am Post subject: |
|
|
Partisan
Joined: 25 Aug 2011
Posts: 377
Location: GU12, UK
|
| If the environment has been that badly managed then all bets are off I think. I'd look to putting together a known baseline for a future deployment and establish basic config management principles. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Mon Feb 13, 2012 5:45 am Post subject: Re: Size of running flows |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| fitzcaraldo wrote: |
Environment WMB V6.x on AIX
I have inherited a poorly managed WMB environment with no reliable records as to what version of each flow is running in production. There is a CVS repository but also additional code that is not in CVS.
I want to know what version of each flow is running but there is no attached metadata. Failing all else, is it possible to determine the size of a .cmf deployed in a given environment and compare that with each candidate version after adding to a bar?
If not - any other ideas? |
And what are your plans to address the strategic root issue?
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| fitzcaraldo |
| Posted: Mon Feb 13, 2012 1:12 pm Post subject: |
|
|
Voyager
Joined: 05 May 2003
Posts: 98
|
Depends what they want to do. In the past we developed a deployment framework that, after building the bar using mqsideploy, opened the bar and appended a version tag to the name of each flow. That was V5.
Can I attach the version tag as metadata to the .cmf itself now? Need to do some reading. |
|
| Back to top |
|
|
| ganesh |
| Posted: Mon Feb 13, 2012 1:17 pm Post subject: |
|
|
Master
Joined: 18 Jul 2010
Posts: 294
|
| Using the CMP api you can get the last modified date of the bar file and deployment date, with that information you could possibly correlate with your source control and find out which version was deployed. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Feb 14, 2012 5:28 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| fitzcaraldo wrote: |
Depends what they want to do. In the past we developed a deployment framework that, after building the bar using mqsideploy, opened the bar and appended a version tag to the name of each flow. That was V5.
Can I attach the version tag as metadata to the .cmf itself now? Need to do some reading. |
The strategic root issue being lax source code control, no documentation, and poor design reviews. What is your plan to address these issues, since you inherited them?
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| marko.pitkanen |
| Posted: Tue Feb 14, 2012 6:18 am Post subject: |
|
|
Chevalier
Joined: 23 Jul 2008
Posts: 440
Location: Jamsa, Finland
|
Hi,
As lancelotlinc asked about best administrative practises here is my piece:
One trick we have been using is that one can not deploy to TEST, UAT, QA or PROD environments from the Toolkit. Instead one have to upload BAR -file to broker machine and use deployment script that stores deployed BAR -file to the folder named by EG and that resides in the file system that moves together with broker from node to other in the case of the take over. We also daily backup broker and mq -objects and databases. We have also scripts that in really disaster can recreate environment from the backups, stored BAR -files etc.
--
Marko |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Feb 14, 2012 7:16 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| marko.pitkanen wrote: |
| One trick we have been using is that one can not deploy to TEST, UAT, QA or PROD environments from the Toolkit. Instead one have to upload BAR -file to broker machine and use deployment script that stores deployed BAR -file to the folder named by EG and that resides in the file system |
This is a sound and common practice. A variation of this is to have the source code uploaded by the developers (or better still checked into source control) and have the deployment script build & deploy the bar file from that.
No solution is better than the other but one is better for the specific site in question, whereever that site might be. The source code solution is a good one where code review policies are lax, or where developers have issues remembering to rebuild bar files when they change code.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Feb 14, 2012 7:25 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
We could start discussing Continuous Integration, Hudson and BuildForge here again. Is anyone up for some more of that?
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Feb 14, 2012 7:29 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| We could start discussing Continuous Integration, Hudson and BuildForge here again. Is anyone up for some more of that? |
I'm done.
Of course, you could post links to the many, many discussions you've had on the subject in here (which would create a useful resource for anyone attempting such a thing).
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Tue Feb 14, 2012 8:02 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| lancelotlinc wrote: |
| We could start discussing Continuous Integration, Hudson and BuildForge here again. Is anyone up for some more of that? |
Surely you mean
Continuous Integration, Jenkins and BuildForge?
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| marko.pitkanen |
| Posted: Tue Feb 14, 2012 9:42 am Post subject: |
|
|
Chevalier
Joined: 23 Jul 2008
Posts: 440
Location: Jamsa, Finland
|
Hi,
Actually in our processes "automatic" continuous integration would be in the development environment where all the development and changes must be done.
We haven't automated our building and unit testing with continuous integration tools.
Instead we have self made scripts for every selected flow that after commit to version controlling system and other environment preparation tasks:
1) builds BAR (yes, we use MQSI keywords for almost every resources with keyword substitution),
2) deploys BAR to development broker,
3) runs unit test scripts,
4) compares output messages to selected version/revision ones
5) takes debug trace and builds code coverage analysis
Developer studies test evidence manually and if everything looks fine commits BAR file to the version controlling system and moves BAR -file and the other needed resources(like queue creation clauses, security identity clauses, configurable service definitions, deployment instructions etc.) to the system testing process. |
|
| Back to top |
|
|
|
|
