| Author |
Message
|
| sleepyjamie |
 Posted: Tue Mar 22, 2016 8:54 am Post subject: How are you versioning your BAR files? |
 |
|
Centurion
Joined: 29 Apr 2015
Posts: 135
|
Coming from the Java/Maven/Gradle world there are conventions and best practices around versioning java-based artifacts. I have not seen any documentation yet from IBM on what they recommend, nor any conventions/standard practises.
I am wondering how others in the community are versioning their BAR files. I see a few options I can go with:
1) use -version flag in mqsicreatebar for application builds
Cons: Renames the Application name with application_version, does not set the VERSION key word in the bar file manifest
2) Name the bar file with the version e.g. MyBar-1.0.bar
Pros: The application name is not modified
Cons: Does not bake the version into the bar file manifest
Ideally I would like to have the version baked into the BAR file at compile time. I have not been able to get the keyword VERSION to contain the version.
Thoughts?
Last edited by sleepyjamie on Tue Mar 22, 2016 9:53 am; edited 1 time in total |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Tue Mar 22, 2016 9:04 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
There is a lot more than just the bar file to it. You might want to have a look at the infocenter. My guess is you want to be able to see the version once looking at the deployed artifact... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| sleepyjamie |
| Posted: Tue Mar 22, 2016 9:34 am Post subject: |
|
|
Centurion
Joined: 29 Apr 2015
Posts: 135
|
| fjb_saper wrote: |
| There is a lot more than just the bar file to it. You might want to have a look at the infocenter. My guess is you want to be able to see the version once looking at the deployed artifact... |
True. This question was more in the context of an application project, where all the dependencies are bundled into a single deployable bar file. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Mar 22, 2016 9:38 am Post subject: Re: How are you versioning your BAR files? |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sleepyjamie wrote: |
| I am wondering how others in the community are versioning their BAR files. |
I don't.
The BAR file is simply a container (unlike, as I'm given to understand, an EAR or WAR file) and has no value once the deployment process is complete.
I (in the sense of the site that has to do what I say with IIB!) set the Version in the flow and / or in the code with the $MQSI construct (some members of this site have trouble with the "do as I say" concept, and believe "standards" are something you fly from a pole. Sigh.) Both of these can be automated, either within the deploy process or the bar build process. Advanced thinkers also embed useful information like author, Agile sprint id and so forth but I don't mandate that.
Aside from these properties being independent of how the BAR file is named and what it contains (standardizing that is like herding cats - I pick my battles), all of these properties have the advantage of being accessible to the Support staff via administrative commands.
And Now My Game Of Thrones moment:
Jenkins Is Coming
I got your "don't understand the standards" right here. Put your head in my mighty CI process and say good bye.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Mar 22, 2016 9:41 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sleepyjamie wrote: |
| True. This question was more in the context of an application project, where all the dependencies are bundled into a single deployable bar file. |
And then you have to enforce all the dependencies being bundled into a single deployable bar file. Or some of them. Or many of them. Or "we're not sure what's in that bar file but it seems to work if you deploy that other one first. And then this one."
Jenkins. I will crush them with Jenkins. The Gits.....
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Mar 22, 2016 9:46 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Other methods of versioning are equally valid and may be more applicable to other circumstances, the value of your investments may go up as well as down and no warranty express or implied is accepted especially when that advice turned into a rant about project teams that can't read standards documents and have to be bolted to an automated deployment process with enough stage gate approvals to sink a battleship.
And then spend their days trying to get an admin password that can do mqsideploy so they can "just put a few quick fixes in".
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sleepyjamie |
| Posted: Tue Mar 22, 2016 10:09 am Post subject: |
|
|
Centurion
Joined: 29 Apr 2015
Posts: 135
|
| Vitor wrote: |
The BAR file is simply a container (unlike, as I'm given to understand, an EAR or WAR file) and has no value once the deployment process is complete. |
I would have to disagree with this statement. This might hold true for integration projects, where a bar file is simply a vehicle for deploying a set of flows or libraries. As mentioned, we are treating our application projects as a single deployable artifact (ie: service), meaning no different than a WAR/EAR.
At our company there is a strong push from mgmt for the teams to be migrating to docker/micro-service environment. As such we have a fully automated CI/CD environment that utilizes GIT, Jenkins, Artifactory, Docker, Ansible, etc...
Thus, we are trying to adopt a micro-services model with docker where we have small, testable, immutable artifacts that can be built and deployed using our CI/CD system. And yes I know IIB is not a micro-service, but many of the good practices that micro-services are built on can apply to IIB application projects.
From a software deployment perspective our application BAR files are categorized as a single deployable artifact that should go through our normal CI/CD process.
| Quote: |
And then you have to enforce all the dependencies being bundled into a single deployable bar file. Or some of them. Or many of them. Or "we're not sure what's in that bar file but it seems to work if you deploy that other one first. And then this one."
|
Correct. We have a single GIT repo (with submodules) that contains our IIB application project dependent libraries, etc. This hasn't been an issue for us because the single bar file represents a specific tag or branch in GIT, which actually makes it easy for developers to pull a specific tag into their dev environment which matches what has been deployed in production. We used to do integration projects and while they offer flexibility they became a maintenance nightmare.
Thus, our GIT tags (e.g. v1.0, v2.0, etc..) will reference a versioned BAR file that is deployed into artifactory and deployed via Ansible into our IIB runtime (stg, prod). So back to my original question. Ideally I want to be able to version the bar file that will match a specific tag/branch in GIT. |
|
| Back to top |
|
|
| sleepyjamie |
| Posted: Tue Mar 22, 2016 10:11 am Post subject: |
|
|
Centurion
Joined: 29 Apr 2015
Posts: 135
|
| fjb_saper wrote: |
| My guess is you want to be able to see the version once looking at the deployed artifact... |
Yeah this is exactly what I would like. Once a BAR file is deployed, how do you find the version at the "Application" level.
Just FYI, we are not versioning our MsgFlows or libraries, Instead we are versioning at the Application/BAR file level. And we always have a single Application per BAR file. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Mar 22, 2016 10:13 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sleepyjamie wrote: |
| Ideally I want to be able to version the bar file that will match a specific tag/branch in GIT. |
I stand by the methods I name above. If you want to version the bar file you can update that automatically.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Mar 22, 2016 10:15 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sleepyjamie wrote: |
| Once a BAR file is deployed, how do you find the version at the "Application" level. |
That's exactly my point about it being a container. What's deployed (and visible in the broker post-deployment) is the Application and the flows it contains. So that's why we tag them.
Now if you want or need to have that tag back to a specific BAR file, have at it and find joy in your life. I still contend (especially in the environment you've described) you're better off tying the deployed code back to a code version in Git.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Mar 22, 2016 10:19 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
To be fair (I'll try anything once) you can determine the name of the bar file that deployed the application, so if your process is as tight as you describe that might be enough for you.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Mar 22, 2016 10:32 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
And how would you deal with the same version but different bar overrides?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Mar 22, 2016 10:43 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| fjb_saper wrote: |
| And how would you deal with the same version but different bar overrides? |
Well you'd hope the different overrides would be caused by different use cases and I would encode those use cases in the application or flow with $MQSI.
The OP could add it to the bar file name (which could rapidly become unwieldy). Though it sounds rather like they produce a single application and deploy it singly ("immutable micro-service") rather than reuse it with different overrides as you describe.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue Mar 22, 2016 10:57 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
Ideally, the creation of the BAR file and the deployment of the BAR file are scripted. Your build/deploy process then looks like this:
- extract the source files *and* the BAR file overrides from the repository using a named tag/branch.
- build the BAR file from the source
- apply BAR overrides using the correct properties file for the target environment
That way, you are guaranteed to have a consistent set of source files and BAR file overrides.
The problem of getting the revision number of each file into the deployed application is a separate problem. Every version control system allows keywords to be inserted into text files, and IIB can exploit that as described here:
https://www.ibm.com/support/knowledgecenter/SSMKHH_9.0.0/com.ibm.etools.mft.doc/ac26550_.htm
_________________
Before you criticize someone, walk a mile in their shoes. That way you're a mile away, and you have their shoes too. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Tue Mar 22, 2016 11:10 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
We make the bar file name include the version number of the major artifact that is inside the barfile.
For example
An Applicatino where the major component is a message flow we version the flow.
My_Interface_113
This is version 1.13.
The filename is My_Interface_113.bar.
The revision history in the Message flow project has the details of the changes for each and every version.
However...
As others have said, use what method works for you.
_________________
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 |
|
|
|
|
