ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » How are you versioning your BAR files?

Post new topic  Reply to topic Goto page 1, 2  Next
 How are you versioning your BAR files? « View previous topic :: View next topic » 
Author Message
sleepyjamie
PostPosted: Tue Mar 22, 2016 8:54 am    Post subject: How are you versioning your BAR files? Reply with quote

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
View user's profile Send private message
fjb_saper
PostPosted: Tue Mar 22, 2016 9:04 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
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
View user's profile Send private message Send e-mail
sleepyjamie
PostPosted: Tue Mar 22, 2016 9:34 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Tue Mar 22, 2016 9:38 am    Post subject: Re: How are you versioning your BAR files? Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Tue Mar 22, 2016 9:41 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Tue Mar 22, 2016 9:46 am    Post subject: Reply with quote

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
View user's profile Send private message
sleepyjamie
PostPosted: Tue Mar 22, 2016 10:09 am    Post subject: Reply with quote

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
View user's profile Send private message
sleepyjamie
PostPosted: Tue Mar 22, 2016 10:11 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Tue Mar 22, 2016 10:13 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Tue Mar 22, 2016 10:15 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Tue Mar 22, 2016 10:19 am    Post subject: Reply with quote

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
View user's profile Send private message
fjb_saper
PostPosted: Tue Mar 22, 2016 10:32 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY

And how would you deal with the same version but different bar overrides?
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
Vitor
PostPosted: Tue Mar 22, 2016 10:43 am    Post subject: Reply with quote

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
View user's profile Send private message
kimbert
PostPosted: Tue Mar 22, 2016 10:57 am    Post subject: Reply with quote

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
View user's profile Send private message
smdavies99
PostPosted: Tue Mar 22, 2016 11:10 am    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » How are you versioning your BAR files?
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.