| Author |
Message
|
| lancelotlinc |
 Posted: Thu Dec 16, 2010 11:06 am Post subject: HOWTO: Assign labels to Bar Files |
 |
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
A recent post asked how to detect if there were two different versions of Bar files deployed. I won't go into a rant or rave about having a Build Engineer on the team just yet.
But here is a good wiki article on release engineering:
http://en.wikipedia.org/wiki/Release_engineering
In particular, developers would help themselves if they printed to syslog the version of bar file they have deployed at EG start time. One way to do this is through MbService.logInformation.
On a Message Flow's property tab, you can specify (assign a label) the Version in the Version field. Use a Wiki page to trace version label assignments.
Knowing what is deployed where gives the Build Engineer, yea the whole Development Tesm, the ability to integrate source, third party components, data, and deployment externals of a software system in order to guarantee operational stability. It's an easy thing to do, and yields great bang-for-the-buck. I wonder why people don't bother to populate the Version field of the Message Flow properties tab?
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Dec 16, 2010 11:54 am Post subject: Re: HOWTO: Assign labels to Bar Files |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| I won't go into a rant or rave about having a Build Engineer on the team just yet. |
You could just post a link to your last rant on the subject... 
| lancelotlinc wrote: |
| I wonder why people don't bother to populate the Version field of the Message Flow properties tab? |
Depressingly, I fear many of the reasons are the same as for "why doesn't everybody have a Build Engineer?". That article does describe a rather more funded, utopian site than is the typical reality.
Which is not to say I don't agree 100% with the value of the Version tag, nor wish it could be populated in a meaningful way here. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Dec 16, 2010 12:02 pm Post subject: Re: HOWTO: Assign labels to Bar Files |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| lancelotlinc wrote: |
| In particular, developers would help themselves if they printed to syslog the version of bar file they have deployed at EG start time. One way to do this is through MbService.logInformation. |
An esql solution would use the LOG statement
http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r1m0/index.jsp?topic=/com.ibm.etools.mft.doc/ak05075_.htm
potentially in a BEGIN atomic block that checked a shared variable such that it's only logged once after startup, not each time the flow runs.
You know, if there are no JCNs in there that have constructors one can use. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Thu Dec 16, 2010 12:21 pm Post subject: Re: HOWTO: Assign labels to Bar Files |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| Vitor wrote: |
| Depressingly, I fear many of the reasons are the same as for "why doesn't everybody have a Build Engineer?". That article does describe a rather more funded, utopian site than is the typical reality. |
Remember that guy I told you about who tried to change the oil in his car with a hammer? He was a corporate jet airplane pilot. His company bought a Learjet and thought the pilot could also do the ground maintnenace. They didn't see a value in having a bunch of Build Engineers standing around on the ground while the pilot was flying. So they gave the pilot a Build Engineer hat. Told him to fix what ever was broke after he flew the plane. Saved them a bunch of money on the ground crew.
Come to thin kof it, it's been a while since I last heard from him. I wonder if he is ok?
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Dec 16, 2010 12:34 pm Post subject: Re: HOWTO: Assign labels to Bar Files |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| Come to thin kof it, it's been a while since I last heard from him. I wonder if he is ok? |
Even if he isn't, the company is rolling round in the money they saved on ground crew like a dog in long grass. And if he's not ok, the insurance will cover any pesky death-in-service issues & the cost of a new plane (assuming they had new-for-old coverage).
Or the guy who decided to save the money on ground crew has picked up his bonus for meeting his cost cutting objectives for that year, moved on (probably to work for BP managing oil rig maintenance) & the new management is sitting round saying, "what idiot decided not to have ground crew?"
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Thu Dec 16, 2010 12:51 pm Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
@Vitor
I like you Vitor. You are A-OK in my book.
@mqjeff
Excellent cross-reference for the ESQL log function, sir. Thanks for the tip.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Dec 16, 2010 1:23 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
@Vitor
I like you Vitor. You are A-OK in my book. |
You're very kind.
| lancelotlinc wrote: |
@mqjeff
Excellent cross-reference for the ESQL log function, sir. Thanks for the tip. |
I find I can apply statistical analysis to project managers, and obtain a Normally Distributed curve, where their decision making policies fall within 1 Standard Deviation of the Mean.
(Since we're talking about project management, the terms "mean" and "deviation" can be taken a number of ways).
Within +/- 1 SD you will get various flavours & intensities of the "fit for purpose", "cost effective", "delivery orientated" sound bite which all come down to "just get it done and get onto the next thing". Obviously this allows for greater or lesser amounts of best practice.
At -1 SD you obtain the "just do it" viewpoint, where code is delivered as fast as possible as cheap as possible, with decreasing levels of quality (and indeed decreasing chance that it actually works) as you slide.
Of course there's also the +1 SD (which seems to be where you live you lucky dog) where the "do it right and if that costs money with no immediate return so be it" viewpoint lives. So I accept these places exist, and are aspirational. I've just spent much more time circling the mean.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Dec 16, 2010 1:57 pm Post subject: Re: HOWTO: Assign labels to Bar Files |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| lancelotlinc wrote: |
| I wonder why people don't bother to populate the Version field of the Message Flow properties tab? |
Because they point to the bar file name attribute and the bar file deploy date that is automatically filled in and say "Seeeeeeeeee, that proves what was deployed."
Uh, no.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Dec 16, 2010 2:12 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| lancelotlinc wrote: |
@mqjeff
Excellent cross-reference for the ESQL log function, sir. Thanks for the tip. |
I was even kind enough to link to it in the v6.1 documentation, rather than assuming that everyone of substance was at v7. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Dec 16, 2010 11:35 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| mqjeff wrote: |
| , rather than assuming that everyone of substance was at v7. |
We are still on 6.1.0.3 and I'm finding it really hard to get them to even consider 7.0.0.1.
Sigh. Take a deep breath, bang head against a wall.
Perhaps 7.0.0.2 might persuade them JSON seems to be flavour of the month at the moment although I shudder to think as letting Mobile (eg iPad) apps have direct access to the broker. And no, a proxy layer is not even on the remotest event horizon.
_________________
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 |
|
|
| lancelotlinc |
| Posted: Fri Dec 17, 2010 5:12 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| Vitor wrote: |
Of course there's also the +1 SD (which seems to be where you live you lucky dog) where the "do it right and if that costs money with no immediate return so be it" viewpoint lives. So I accept these places exist, and are aspirational. I've just spent much more time circling the mean. |
Au contrar, Sir Vitor. I have an Eagle-eye for return-on-investment. My resume says so!
Using the find-it-fast bug curve (remember the one where the earlier in the process you find a bug, the cheaper it is to fix?), you can pay for some of the more extravagant process-oriented rigors. I find automation tools invaluable. A team of five is like a team of fifty with Ant, Maven, Hudson, and Junit.
The immediate return is not having to babysit production deployments; reduced overtime; doing 80 message flows in six months. Knowing the actual ~100 ms latency of every transaction that flows through the ESB; ability to push the 3,000 TPS envelope on a skinny hardware system. That my friend is nirvana.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Dec 17, 2010 5:19 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| Au contrar, Sir Vitor. I have an Eagle-eye for return-on-investment. My resume says so! |
At one point, my resume said, "experience with Java development".
| lancelotlinc wrote: |
| Using the find-it-fast bug curve (remember the one where the earlier in the process you find a bug, the cheaper it is to fix?), you can pay for some of the more extravagant process-oriented rigors. I find automation tools invaluable. A team of five is like a team of fifty with Ant, Maven, Hudson, and Junit. |
As I've said before, I envy your ability to convince management of this undisputed fact.
| lancelotlinc wrote: |
| The immediate return is not having to babysit production deployments; reduced overtime; doing 80 message flows in six months. Knowing the actual ~100 ms latency of every transaction that flows through the ESB; ability to push the 3,000 TPS envelope on a skinny hardware system. That my friend is nirvana. |
And the roadblock is the lack of short term progress while you're building nirvana.
You work on a better site than I do and I have. We can stop discussing it. Your method is utopian & I'm pleased for you that you have it. Have pity for me in my world and the fellow sufferers (like smdavies99 - at least my lot have a plan to move off the out of support software).
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bsiggers |
| Posted: Wed Dec 22, 2010 9:01 am Post subject: Using source control keywords? |
|
|
Acolyte
Joined: 09 Dec 2010
Posts: 53
Location: Vancouver, BC
|
Hello - was just working on some source code control stuff and change management process, and have managed to populate the Version field automatically on Message Sets and Message Flows, as well as in ESQL and Java using comments. Just fill it in with $Id$ and out comes something like $Id: messageSet.mset 85 2010-12-21 17:42:03Z bsiggers $.
Important is that it contains the revision# (85) for tracability. You can do this in both Subversion and CVS.
To do this in Subversion you need to set the svn:keywords to 'Id' for files you want to do this for (.msgflow, .mset, .java, .esql) - this can also apparently be done automatically.
It's not perfect, but it's better than nothing - I don't believe that any non-automated solution would make this change consistently enough to be usable. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Thu Dec 23, 2010 8:23 am Post subject: Re: Using source control keywords? |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| bsiggers wrote: |
Hello - was just working on some source code control stuff and change management process, and have managed to populate the Version field automatically on Message Sets and Message Flows, as well as in ESQL and Java using comments. Just fill it in with $Id$ and out comes something like $Id: messageSet.mset 85 2010-12-21 17:42:03Z bsiggers $.
Important is that it contains the revision# (85) for tracability. You can do this in both Subversion and CVS.
To do this in Subversion you need to set the svn:keywords to 'Id' for files you want to do this for (.msgflow, .mset, .java, .esql) - this can also apparently be done automatically.
It's not perfect, but it's better than nothing - I don't believe that any non-automated solution would make this change consistently enough to be usable. |
Precisely. Then track key message flow version numbers on a Wiki page to compare with deployed BARs. The Wiki page becomes a quick reference list for the ...eh hum... Build Engineer.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Dec 23, 2010 8:47 am Post subject: Re: Using source control keywords? |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| Precisely. Then track key message flow version numbers on a Wiki page to compare with deployed BARs. The Wiki page becomes a quick reference list for the ...eh hum... Build Engineer. |
So what do I need to set in Subversion to make a Build Engineer appear? 
| lancelotlinc wrote: |
| A team of five is like a team of fifty with Ant, Maven, Hudson, and Junit |
We've talked before about your site being better in almost every way to mine. Let me give you some background about this site, and see if you have any suggestions about what I can do to advance your cause:
I have a WMB development team of two and a half, where I'm one of the 2 and the half is a Cobol developer who's trying to write ESQL for some of the more complex business cases. Yes, we have business logic in WMB.
We have Subversion, but politically it's for "finished" code. Bar files are built and deployed manually rather than Ant et al because we have no environment in which to build that isn't the developer's desktop. Bar deploys into non-Dev environments are also done manually and suggestions that we could partially automate it using bar file overrides have fallen on deaf ears because "that's just an extra step".
We don't use JUnit for testing. Testing is done by business users inputing data into the UI or running files on the mainframe. I've just managed to get them not to enter 5 test cases with the same address so I can tell them apart in the trace, they're considering my suggestion that the test cases be something I've called "scripted", i.e. not just made up on the fly as something representative and my complaints that they shouldn't be doing business acceptance testing in the Dev environment has been met with a blank look and the comment "but we need to test the code so soon as possible; we're late and this is an Aglie environment".
We are late. They were 18 months late when I started here 3 months ago and are a year late now (some things dropped from scope, some people got trouted) and the political pressure to get things delivered so the business can see where the money's been spent is intense.
Trust me, I'd love a Build Engineer role here. I've love proper source control, automated build and a deploy process you could rely on (one where I didn't have to check the Test environment every time to see if they've deployed the bar files and added the new rows to our standing info database). I'd love testing where all the test cases didn't have the same details (though to be fair I now know where the chief tester lives and will have an alibi if it catches fire) and where the test data had some order, or at least relevance to the business.
I'd like management backing. I'd like someone to agree that it's a mess, and some time spent fixing the process is an investment. Not just say "we'll look into it once this development phase is finished; why don't you put together a document?"
Can you get me that for Xmas?
Season's greetings to all 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
