| Author |
Message
|
| PeterPotkay |
 Posted: Thu Mar 03, 2005 6:07 pm Post subject: Bar files that contain source code |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Currently we are storing the bar file in pvcs, and also along side it the esql file, the msgflow file, the mset file, etc.
I heard that you can put anything you want in a bar file. I was thinking about storing these source code files in the bar file, so that this one bar file is the only thing I have in PVCS. If I open that bar file, I know for a fact what source code was used to create it.
It is my understanding that when you deploy a bar file with other "stuff" in it, the config managers know enough just to deploy the executable code. Meanwhile, I can use WinZip to open the bar file and look at the esql file, or import the mset file, etc.
Comments? Anyone else housing version notes, source code, jpegs of their dog, etc in their bar files?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| martinrydman |
| Posted: Fri Mar 04, 2005 12:09 am Post subject: |
|
|
Centurion
Joined: 30 Jan 2004
Posts: 139
Location: Gothenburg, Sweden
|
Hi,
There's a checkbox in the Add to broker archive dialog box that says Include message flow/set source, which pretty much meets your requirement 
We're also thinking of doing this. That way, once a .bar has been delivered to the prod team and stored in CVS, you can always re-create the exact project that runs in prod, even if you've screwed up your version tags or whatever.
/Martin |
|
| Back to top |
|
|
| nathanw |
| Posted: Fri Mar 04, 2005 1:03 am Post subject: |
|
|
Knight
Joined: 14 Jul 2004
Posts: 550
|
Yes
basically it means that if yu include the source files / code it copies into the BAR all the flows etc that have been changed on this iteration and all the older ones that are unchanged
On a previous project I used this as a sort of versioning system (I know there are better ones out there) and kept a copy of the BAR elsewhere
I suppose as long as you can get the "item(s)" in there and you can extract them out then you can store whatever you like in there
N |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Mar 04, 2005 5:30 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Peter -
Your developers might not appreaciate this.
You should keep the message flows and sets as separate projects in your version control system.
When you go to build a bar file, you should indeed do something to keep track of what version of source code went into it - like you would with any other type of release. But nobody puts java code into EAR files, and nobody puts source code into C executeables... It's a waste of space.
PVCS should allow you to tag a particular set of source code at the time you do a build, and always retrieve the right code by that tag. This would then allow your developers to do their own tagging and maintenance.
But really, they shouldn't be releasing stuff to be deployed except at milestones and for maintenance fixes. So your tags should conform to their tags.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Mar 04, 2005 9:41 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| jefflowrey wrote: |
PVCS should allow you to tag a particular set of source code at the time you do a build, and always retrieve the right code by that tag. |
Ah, but now there is an additional manual step. A human on my team needs to insure that the bar file and the esql file and the mset file etc all have the PVCS tag. And at this point, we are assuming that the developers sent us the correct files, and all the files.
But if there is just one bar file that we get, it is up to the developers to include all the source with it. We name our bar files ExecutionGroupName_ReleaseDate. Since WB-IMB does not allow any easy way to see exactly what is running after it is deployed, it is hoped that whenever there is a question of what source is out there, we just go find the latest BAR file. We know 99.99999% that this bar file was the last one deployed, so if we unzip it, we can be 99.999998% sure that the source code in the bar is a representation of what is out there actually running. It also saves time, since we promote just one file (BAR) in PVCS, instead of the BAR and all the other source files. Less room for error and faster.
As for the space saving question....I don't think space is an issue. You either store it in one bar file (which is zipped/compressed), or you store all the files separatly, which probably takes more room.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Mar 04, 2005 10:37 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| PeterPotkay wrote: |
| As for the space saving question....I don't think space is an issue. You either store it in one bar file (which is zipped/compressed), or you store all the files separatly, which probably takes more room. |
We're obviously talking about completely different deployment workflows. So I'm going to assume that the rest of the stuff you're doing makes sense to you.
My point about saving space is that you should already be keeping the message flow and message set projects in the PVCS repository, and they should be tagged in such a way that indicates which version of source went into which bar file. IF you do that, then adding the uncompiled source to the BAR file is wasting space, because it's duplicating the existing source.
The other question regarding space is that I don't know if the broker puts the uncompiled source into the broker database or not. If it does, you're taking up extra space in your broker database.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Heinz57 |
| Posted: Fri Mar 04, 2005 11:41 am Post subject: |
|
|
Apprentice
Joined: 21 Jan 2004
Posts: 26
Location: Syracuse, NY
|
Peter,
Your suggestion does sound interesting but beware of a limit. We have found that you cannot deploy a BAR file > than 10mb. If you store everything within the BAR you may reach 10mb faster than you expect.... Unless this restriction is corrected in future releases... We're at v5 CSD 4. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Mar 04, 2005 1:17 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Jeff, I see your point now. t may be weeks or months before the developers send me the bar file for a deploy. Where would they house their code in the meantime - presumably they would want to keep it in PVCS, not yet in a bar file.
Heinz, is that 10MB limit documented?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Mar 04, 2005 2:23 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Peter -
My main point is that developers need their projects under version control, for managing development. Since that's the case, you might as well reuse their tagging for your purposes. And since it's already there, why duplicate the code?
And Heinz' point about the size limit. Also, deployment happens by way of MQ, so there are message size limits that may get hit (channels, queues, qmgrs) also... Default MAXMSGLN being 4MB, that is.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Mar 04, 2005 2:31 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
But when you deploy a bar file that contains other stuff, does the the Config manager ship all that other junk over MQ to the Broker, where the Broker sorts out only the executable runtime code. Or does the CM know enough only to ship the executable runtime code, leaving behind the useless (for a deploy) source code?
The fact that the developers will be housing their source separatly in PVCS before they ever create a bar file means that source will be there anyway in PVCS, just like you said. We will just have to keep the tags between the source and the bars synced up. And hope we never really have to rely on it, since we can't be 100% sure that the message flow running was produced by a particular bar file. And you can never tell 100% what source code was used to create a bar file. I wish IBM would allow a way to right click on a running flow and extract some info like a version tag that you could tie back to the source code that created the running flow.....
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Mar 04, 2005 2:42 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The PASSTHRU (or passthrough?) node is designed to exactly allow you to identify what version of a sub flow has been hit in a trace. It may work just as well for a main flow.
And it's entirely possible that the configmgr passes everything to the broker and the broker stores the ENTIRE bar file in it's database...
Maybe someone who's seen the source will tell us.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| martinrydman |
| Posted: Sat Mar 05, 2005 6:36 am Post subject: |
|
|
Centurion
Joined: 30 Jan 2004
Posts: 139
Location: Gothenburg, Sweden
|
Somehow this whole thread springs from the fact that there is no easy and automated way to know for sure what exactly is deployed. Anyone know if IBM has any plans in this area?
I read the IC04 (Change Management and Naming Standards) and there are obviously ways to adress this problem, but it seems strange that a resource in an execution group could not simply get a couple of properties that automatically gets updated with, say, a versioning systems tag or version number, or whatever.
It would save us all time and eliminate the hazards of relying on peoples ability to stay diciplined.
/Martin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Mar 05, 2005 8:09 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I opened an official request with IBM on this capability. The agree it is desireable and accepted it, but make no promises.
Seems like such a basic thing to have the ability to do.....
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Paul D |
| Posted: Mon Mar 07, 2005 6:31 am Post subject: |
|
|
Master
Joined: 16 May 2001
Posts: 200
Location: Green Bay Packer Country
|
I suggest using the pass thru node to version, and also build an ANT script to do your builds of BAR files. This can call PVCS from the build script. Use a labeling scheme and do a "get by label" and you will have control of your source. The deployment descriptor broker.xml can be manupulated also to have a fully automated build. Have application areas do their production builds this way. Even other "controlled" environments just before prod also.
_________________
Thanks!!!
Paul D |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Mar 07, 2005 6:38 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Can you automate the import of Projects from ant? That seems to be one of the sticking poitns for fully automating broker deploys - importing the projects into the workspace so that mqsicreatebar can work successfully.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
