| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Planning Continuous Integration with Jenkins and WMB 8.0 |
« View previous topic :: View next topic » |
| Author |
Message
|
| ruimadaleno |
 Posted: Wed Jul 29, 2015 3:19 pm Post subject: Planning Continuous Integration with Jenkins and WMB 8.0 |
 |
|
Master
Joined: 08 May 2014
Posts: 274
|
Twos month ago we have changed the deployment process in our broker environment (in short: deployment was done via message broker explorer and now is done via scripts: properties files + bar files + mqsideploy + mqsiapplybaroverride)
Now we are looking for the next step: automation
And this is were the doubts begin 
The tool to be used is Jenkins (because there is some knowledge in house - using jenkins for testing automation)
Source code is kept in SVN (subversion)
We have 3 environments (Production, Staging and Development), running websphere message broker 8.0.0.5 on windows server 2008 r2
What are we looking we looking for ? Automation for the following steps
1) Get the source code from SVN
2) Compile - create bar file (mqsicreatebar)
3) Apply/override properties - properties file + mqsiapplybaroverride
4) Deploy bar file in the proper execution group in the target environment
we have done some tests in developers local machines and we have successfully run the above steps with a jenkins build (it must be improved, but, the proof of concept is completed)
Some questions are floating in our minds, and we like to ear from your experience on this subject.
the first one is:
Do we need to install jenkins in every broker environment ? or by the other hand, can we install and configure a jenkins server for deployment on every broker environment ? if yes, it means that, somehow, jenkins has the ability to execute remote commands or the broker client has the ability for remote deployment ?
_________________
Best regards
Rui Madaleno |
|
| Back to top |
|
 |
| stoney |
| Posted: Wed Jul 29, 2015 9:11 pm Post subject: |
|
|
Centurion
Joined: 03 Apr 2013
Posts: 140
|
The mqsideploy command can connect to remote brokers:
| Code: |
| mqsideploy -i myhost.ibm.com -p 1414 -q MB8QMGR -e default -a /path/to/file.bar |
This means that you don't have to deploy Jenkins on the host that your brokers are running on.
You can have one host running Jenkins that can remotely deploy to multiple brokers on multiple hosts.
However, you do have to have an installation of WMB available for Jenkins to use to connect to the remote brokers.
Since you are using mqsicreatebar, you will also need to install the WMB toolkit on the Jenkins host. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Wed Jul 29, 2015 10:09 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
I hope you code your scripts so that you get a defined version from SVN. Otherwise you may deploy untested code to production.
There are some interesting discussions here about object deployments and the plusses and minuses of creating something that can be deployed to all environments without needing any changes (incluing bar file overrides)
Let me say at the outset that I'm of the old school in that a bar file is a deployable object and IMHO it should not be altered in any way when deploying it to DEV, SYStest, UST, Pre-Prod or Prod. Other can (And do) disagree. If you can be 1 million, gazillion percent sure that any bar file override done betweent DEV and PROD won't mess up the flow etc then go ahead and implement it. (I can hear the cheers from part of the audience already).
I just like the certanty of checing out a version bar file and knowing that I can test it, UAT it and deploy it to PROD with no changes.
But as I said, I'm an old  whose  in gainful employment is fast running out.
_________________
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 |
|
|
| fjb_saper |
| Posted: Thu Jul 30, 2015 4:44 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
Being old school says it all. Where it is feasible to have the same bar file override properties in all environments when you are running MQ only, it is typically impossible to implement when running with HTTP and SOAP nodes as the URLS change between environments...
So while yes the override property files should be in version control there also should be a distinctive one per environment.
Not to say there isn't a way to set this all up in a configurable service, but this gets complicated fast and a bar override property file might be the easiest and fastest / cheapest way to go. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jul 30, 2015 4:59 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| smdavies99 wrote: |
| I hope you code your scripts so that you get a defined version from SVN. Otherwise you may deploy untested code to production. |
This is a key point that a lot of people overlook. Especially as it's not a problem when you release your new automation to a small group of early adopters as a post-beta test pilot but is a problem when you give it to a large team that has a greater chance of tripping over itself.
| smdavies99 wrote: |
| Let me say at the outset that I'm of the old school in that a bar file is a deployable object and IMHO it should not be altered in any way when deploying it to DEV, SYStest, UST, Pre-Prod or Prod. Other can (And do) disagree. If you can be 1 million, gazillion percent sure that any bar file override done betweent DEV and PROD won't mess up the flow etc then go ahead and implement it. (I can hear the cheers from part of the audience already). |
Let me say at the outset that my school is of the same vintage as my worthy associate, and I'm perfectly content doing bar file overrides for all the environments between Dev & Prod. Yes, this does mean for each environment the bar file is "different" and yes, it does mean that there's an element of risk the code won't work. My experience is that errors are about 50% misspelt DataSource names, 50% misspelt URLs.
In defence, we've augmented our deployment automation to scan properties files and weed out the obvious blunders; Prod properties files that have ".qa." in the URLs because they're created by copying an earlier version or ODBCs that have "Q" in the 4th position not "P" for the same reason. It's not foolproof; a wise man once said "invent a foolproof system and someone will invent a better fool". We still get problems and dealing with those is a political process, specifically assigning the ticket to the project for resolution as a code issue rather than a platform configuration problem. Round here, that stings. I also circulate a "<Vitor's Real Name> Believe It Or Not" of incredible errors; my personal favorite is the project that, having signed off on all their testing and the properties review we make them do before Prod implementation had 5 SOAPRequest nodes pointing to various URLs ending ".websrevice"
The point is that IMHO it's better to have one copy of the executable code in the bar file and update it as it moves forward. If you build one copy for each environment, sooner or later someone will deploy the QA bar file to Prod (I refer to my comment above about foolproof systems). You should also ensure that when the bar file is built (however many bar files you decide to have) you include Version and Key word information to identify in the runtime what SVN version the code is and when it was edited. A common comment in any Problem troubleshooting conversation (especially in non-Prod) is "are you sure that's the latest version with that last fix that you're running?".
As has been previously commented, you only need a single build machine that has remote access to the target broker. We actually split it; we build, store the bar file and associated environment property files in a separate repository to the source (it's not that we don't trust the developers, it's just that we don't trust the developers) and deploy from that. This also means the build process and server (which we don't own) doesn't need any access to the runtime environments (which we do own).
It's only paranoia if they're not actually after you.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| ruimadaleno |
| Posted: Thu Jul 30, 2015 2:20 pm Post subject: |
|
|
Master
Joined: 08 May 2014
Posts: 274
|
| stoney wrote: |
The mqsideploy command can connect to remote brokers:
| Code: |
| mqsideploy -i myhost.ibm.com -p 1414 -q MB8QMGR -e default -a /path/to/file.bar |
This means that you don't have to deploy Jenkins on the host that your brokers are running on.
You can have one host running Jenkins that can remotely deploy to multiple brokers on multiple hosts.
However, you do have to have an installation of WMB available for Jenkins to use to connect to the remote brokers.
Since you are using mqsicreatebar, you will also need to install the WMB toolkit on Jenkins host. |
Hi Stoney, thank you for your help.
so we can install just one server with jenkins to deploy remotely on several broker environments ! great !
I understand i must install some kind of "broker client" in the jenkins server to get the commands and runtime environment available to the jenkins server, but, do i need a full wmb installation on jenkins server ? if my broker environment runs on advanced mode can i install WMB in "Standard mode" in the jenkins server (i'm thinking about licensing ... $$$$$) . If i install WMB do i really need WMB toolkit in the jenkins server ?
_________________
Best regards
Rui Madaleno |
|
| Back to top |
|
|
| ruimadaleno |
| Posted: Thu Jul 30, 2015 2:25 pm Post subject: |
|
|
Master
Joined: 08 May 2014
Posts: 274
|
| fjb_saper wrote: |
Being old school says it all. Where it is feasible to have the same bar file override properties in all environments when you are running MQ only, it is typically impossible to implement when running with HTTP and SOAP nodes as the URLS change between environments...
So while yes the override property files should be in version control there also should be a distinctive one per environment.
Not to say there isn't a way to set this all up in a configurable service, but this gets complicated fast and a bar override property file might be the easiest and fastest / cheapest way to go. |
Hi fjb_saper,
right now the properties files ( used to override the bar) are kept in SVN, We have one properties file for each service/app for each environment.
SVN tree is something like:
Properties_Files
|...... PROD
| (properties files for prod environment here - one for each service/app)
|
|......QUA
| (properties files for qualification environment here - one for each service/app)
|
|..... DEV
| (properties files for development environment here - one for each service/app)
_________________
Best regards
Rui Madaleno |
|
| Back to top |
|
|
| ruimadaleno |
| Posted: Thu Jul 30, 2015 2:37 pm Post subject: |
|
|
Master
Joined: 08 May 2014
Posts: 274
|
Hi Vitor/smDavies
thank you both for you valuable knowledge sharing 
Vitor, you said:
| Quote: |
The point is that IMHO it's better to have one copy of the executable code in the bar file and update it as it moves forward. If you build one copy for each environment, sooner or later someone will deploy the QA bar file to Prod (I refer to my comment above about foolproof systems). You should also ensure that when the bar file is built (however many bar files you decide to have) you include Version and Key word information to identify in the runtime what SVN version the code is and when it was edited.
|
how do you record the svn revision number in the bar file ? i know you can edit version and keywords ($MQSI xxx = zzz MQSI$) in development time, but , how can this be done in deployment time ?
| Quote: |
A common comment in any Problem troubleshooting conversation (especially in non-Prod) is "are you sure that's the latest version with that last fix that you're running?". |
I understand that, somehow in the deployment process, you record the SVN revision number in the bar file. Where do you check this value when troubleshooting? message broker explorer ? mqsi command ? web console ?
_________________
Best regards
Rui Madaleno |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jul 31, 2015 4:01 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| ruimadaleno wrote: |
| do i need a full wmb installation on jenkins server ? |
No, as indicated above you need the Toolkit.
| ruimadaleno wrote: |
| if my broker environment runs on advanced mode can i install WMB in "Standard mode" in the jenkins server (i'm thinking about licensing ... $$$$$) . |
If all the Jenkins server is doing is build & deploy, why not the Developer edition? It's free.
| ruimadaleno wrote: |
| If i install WMB do i really need WMB toolkit in the jenkins server ? |
Yes. Commands like mqsicreatebar are part of the Toolkit install not part of the runtime.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jul 31, 2015 4:08 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| ruimadaleno wrote: |
Vitor, you said:
| Quote: |
The point is that IMHO it's better to have one copy of the executable code in the bar file and update it as it moves forward. If you build one copy for each environment, sooner or later someone will deploy the QA bar file to Prod (I refer to my comment above about foolproof systems). You should also ensure that when the bar file is built (however many bar files you decide to have) you include Version and Key word information to identify in the runtime what SVN version the code is and when it was edited.
|
how do you record the svn revision number in the bar file ? i know you can edit version and keywords ($MQSI xxx = zzz MQSI$) in development time, but , how can this be done in deployment time ? |
If you only build the bar file once (as I described) then the version & svn keywords don't change from deployment to deployment. This is a good thing as the executable code you've tested doesn't change.
If you want to add keywords at deployment time (remembering that IIB automatically records deployment date, deployment time & source bar file for all components) you can use ant (or similar) to edit the deployment descriptor. Rather less common that & I'd be interested to know your requirement there - what aside from the automatically harvested details I mention above would you want to record?
| ruimadaleno wrote: |
| Quote: |
A common comment in any Problem troubleshooting conversation (especially in non-Prod) is "are you sure that's the latest version with that last fix that you're running?". |
I understand that, somehow in the deployment process, you record the SVN revision number in the bar file. Where do you check this value when troubleshooting? message broker explorer ? mqsi command ? web console ? |
Yes. The Version and all the added keywords show up in all those places.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| ruimadaleno |
| Posted: Fri Jul 31, 2015 5:46 am Post subject: |
|
|
Master
Joined: 08 May 2014
Posts: 274
|
| Quote: |
Rather less common that & I'd be interested to know your requirement there - what aside from the automatically harvested details I mention above would you want to record?
|
Hi Vitor.
the message broker servers are managed by third party entity.
Every time we need to deploy a service/app to a broker environment we need to create a service request (SR).
Each service request gets a single number that identifies it.
The third party provider then executes the service request (it executes the scripts) and deploys services/apps to target broker environemnt.
So, what i was trying to understand is:
is it possible, in deployment time, to include in the bar file a keyword named "SR" or "ServiceRequest" that holds the number of the service request ? This info would be helpfull in troubleshooting because i would be able to check deployment date/time, bar file name deployed and the service request were the deployment was triggered.
_________________
Best regards
Rui Madaleno |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jul 31, 2015 6:10 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| ruimadaleno wrote: |
| Quote: |
Rather less common that & I'd be interested to know your requirement there - what aside from the automatically harvested details I mention above would you want to record?
|
Hi Vitor.
the message broker servers are managed by third party entity.
Every time we need to deploy a service/app to a broker environment we need to create a service request (SR).
Each service request gets a single number that identifies it.
The third party provider then executes the service request (it executes the scripts) and deploys services/apps to target broker environemnt.
So, what i was trying to understand is:
is it possible, in deployment time, to include in the bar file a keyword named "SR" or "ServiceRequest" that holds the number of the service request ? This info would be helpfull in troubleshooting because i would be able to check deployment date/time, bar file name deployed and the service request were the deployment was triggered. |
Makes sense.
You can probably do what you want by following this guidance for Adding version information to an application or library at deployment time but for an SR keyword not a version. If it was me, I'd include a keyword SR=NNNNNN at build time and edit it in the deployment rather than add it, but that's me. Someone may well be along with a better idea in a moment.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| ruimadaleno |
| Posted: Sat Aug 01, 2015 11:11 am Post subject: |
|
|
Master
Joined: 08 May 2014
Posts: 274
|
| Vitor wrote: |
| ruimadaleno wrote: |
| Quote: |
Rather less common that & I'd be interested to know your requirement there - what aside from the automatically harvested details I mention above would you want to record?
|
Hi Vitor.
the message broker servers are managed by third party entity.
Every time we need to deploy a service/app to a broker environment we need to create a service request (SR).
Each service request gets a single number that identifies it.
The third party provider then executes the service request (it executes the scripts) and deploys services/apps to target broker environemnt.
So, what i was trying to understand is:
is it possible, in deployment time, to include in the bar file a keyword named "SR" or "ServiceRequest" that holds the number of the service request ? This info would be helpfull in troubleshooting because i would be able to check deployment date/time, bar file name deployed and the service request were the deployment was triggered. |
Makes sense.
You can probably do what you want by following this guidance for Adding version information to an application or library at deployment time but for an SR keyword not a version. If it was me, I'd include a keyword SR=NNNNNN at build time and edit it in the deployment rather than add it, but that's me. Someone may well be along with a better idea in a moment. |
Hi Vitor,
so, one solution would be to create a SR=NNN keyword in every message flow that is built and deployed in our environments. This rule must be included in our development policy, so every developer that builds a message flow creates the SR keyword and populates it.
I see two problems here:
1) A developer building a message flow that does not apply the rule and delivers a message flow without the SR keyword (it's not that we don't trust development team, but with external development teams sometimes it's ... tricky  )
2) Sometimes we get the service request number latter (our third party provider may take some time to schedule our request and inform the service request number). So, by the time development team finishes the message flow we are not aware of the service request number that will publish the message flow.
How would you handle this constraints ? One solution would be, at deployment time, add the SR keyword to bar file but mqsiapplybaroverride command is not capable to achieve this result. Reading documentation i understand that one solution would be to add the keyword to META-INF/keywords.txt inside the bar, but documentation is not clear (at all) on how this can be achived ? is there any mqsi command ?can this be done with ant (i'm assuming that a bar file is just like an ear/war file whose deployment descriptor can be altered)
_________________
Best regards
Rui Madaleno |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Sat Aug 01, 2015 10:02 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| ruimadaleno wrote: |
1) A developer building a message flow that does not apply the rule and delivers a message flow without the SR keyword (it's not that we don't trust development team, but with external development teams sometimes it's ... tricky )
|
That's easy. Reject the flow and send it back to the external dev team.
If it does not meet your standard then reject it.
Been there, done that. The 3rd party soon learn to make the stuff they deliver bullet-proof so that our QC fo their work becomes easier. IF they don't, find another 3rd party. There are plenty of others out there. (especially in South Asia)
As for the other point you raised.
How about allocating some SR numbers in advance and then calling them off when you need them. A sort of framework just to get the number allocated. Then you fill in the details when you come to use it. You can then make everything line up.
The problem comes when the 3rd party wants to charge you at that point in time OR that there is some SLA with the 3rd party that dictates how long a request can be open before falling foul of the SLA.
This is not something that can not be sorted out given time and a willingness of both parties.
_________________
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 |
|
|
| Vitor |
| Posted: Mon Aug 03, 2015 5:25 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| ruimadaleno wrote: |
| 1) A developer building a message flow that does not apply the rule and delivers a message flow without the SR keyword (it's not that we don't trust development team, but with external development teams sometimes it's ... tricky ) |
Place a simple check in the deployment process that automatically rejects source that doesn't have such a keyword in the same way it rejects code that doesn't deploy to the execution group. The teams will quickly get the idea.
| ruimadaleno wrote: |
| 2) Sometimes we get the service request number latter (our third party provider may take some time to schedule our request and inform the service request number). So, by the time development team finishes the message flow we are not aware of the service request number that will publish the message flow. |
I don't think I was completely clear. I actually meant adding a keyword "SR=NNNNNN" with as many "N" as you have digits in the SR number, and editing it to the value when available in the bar file itself; ideally through an automated change or deployment process. This is much easier than inserting it, and a key reason I suggested having a human put it in.
So the developer just needs to remember to add the placeholder, and will be reminded when their code rejects.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
|
  |
Goto page 1, 2, 3 Next |
Page 1 of 3 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
