| Author |
Message
|
| JohnSmith |
 Posted: Tue Sep 14, 2010 6:58 am Post subject: Good approach : Single BAR file for all flows/msets? |
 |
|
Voyager
Joined: 17 Mar 2010
Posts: 86
|
Hello,
Need to check , whether it is a good approach to create a single BAR file for all the flows and message sets in a project. We are currently finalizing our Release and change process where one of the point that has been kept is to keep all the Flows and msg sets together in a single bar file, so that whenever we deploy, need to deploy only 1 bar file.
But I have few points to make here.
1. In our case the number of flows/msg sets are around 120 in number, which will probably makes the BAR file huge and hence problem in deploying
2. A very minor fix in only one of the flows/msgsets will again force us to build the rebuild and deploy all the flows which would unnecessary be time consuming.
These are my observations, feel free to pitch in your comments.
thanks. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue Sep 14, 2010 7:07 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
I don't think there's a "right" answer to this question.
IMHO you want to keep the number of flows per bar file down to prevent exactly the problem you describe where a single simple change causes a complete redeploy. I've also been on sites where (legitimately) they see that as a virtue because a code deploy is part of a near-complete rebuild of the target environment. Even if you decide to limit the flows & message sets to those "logically related", defining that relationship is an art not a science.
Points I feel should influence any decision:
- How large does the bar file become with all of the flows? How much of a problem is it?
- If it's a problem, what's the largest bar that's "workable" (whatever that means for you)
- How is the bar file built? Is it scripted and easily broken down? What is the risk of human error with multiple bar files?
There are undoubtably other points. There are undoubtably other opinions, and I might agree with some or all of them.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| JohnSmith |
| Posted: Tue Sep 14, 2010 7:14 am Post subject: |
|
|
Voyager
Joined: 17 Mar 2010
Posts: 86
|
| Quote: |
I don't think there's a "right" answer to this question.
IMHO you want to keep the number of flows per bar file down to prevent exactly the problem you describe where a single simple change causes a complete redeploy. I've also been on sites where (legitimately) they see that as a virtue because a code deploy is part of a near-complete rebuild of the target environment. Even if you decide to limit the flows & message sets to those "logically related", defining that relationship is an art not a science.
Points I feel should influence any decision:
- How large does the bar file become with all of the flows? How much of a problem is it?
- If it's a problem, what's the largest bar that's "workable" (whatever that means for you)
- How is the bar file built? Is it scripted and easily broken down? What is the risk of human error with multiple bar files?
There are undoubtably other points. There are undoubtably other opinions, and I might agree with some or all of them. |
Thanks Vitor for the reply, my real concern is SIT/UAT environment (it is PROD which I am least bother). As SIT/UAT environment are the one which can gets code fixes/change request every alternate day or may be every day or possibly multiple times in a day with some defects on SEV1 and Sev2 which requires fix to be deployed in few hours time.
In that case building a complete BAR file and deploying them will obviously consume time and considerably requires long duration of downtime on the environment compare to the case where we have multiple bar files for flows and can deploy only that bar file keeping everything else running. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Sep 14, 2010 7:33 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Only redeploy the things that are changed.
At least for SIT.
For UAT/QAT, you might do a nightly build/deploy of the whole environment and then do specific deploys for specific tests during the day.
For Prod, you should have a package for each given release, based on whatever constitutes a release in your change management strategy. |
|
| Back to top |
|
|
| paustin_ours |
| Posted: Tue Sep 14, 2010 7:48 am Post subject: |
|
|
Yatiri
Joined: 19 May 2004
Posts: 667
Location: columbus,oh
|
This is one area, i would really love a developer works article or a best practices doc from IBM. In our area we have one bar file for every flow and every set. This way it helps with maintaing what gets deployed and whats out there.
whenever we deploy even a minor change to one of the flows to a project. We remove everything from that EG. do a build again and do a bar over ride again and then deploy the whole damn thing again.
one way we are following to keep track of versions. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Sep 14, 2010 7:52 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
|
| Back to top |
|
|
|
|
