| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Waterfall Code Version Control |
« View previous topic :: View next topic » |
| Author |
Message
|
| nelson |
 Posted: Fri Jun 05, 2015 1:44 pm Post subject: Waterfall Code Version Control |
 |
|
Partisan
Joined: 02 Oct 2012
Posts: 313
|
Hi all,
We have the challenge to control the source code from many layers in a waterfall way, from the channels layers that consume services, to the back end providers systems.
Is there a way to orchestrate source version in a way that if the highest layer(s) needs to rollback some of its component to a previous version (some feature at functional level), we have the ability to checkout those (technical) components involved at the broker layer too, that could be a 1-1 or a 1-n relationship.
Is this a crazy idea? In your experience, source control in broker is managed in an isolated way from the other layers? How can we organize our projects/applications/libraries in broker?
Usually one application/library has a lot of services/flows/components that is very hard to say.... "If you roll back your X functional feature at the highest level, in broker you will need to roll back Y,W,Z flows, or just W flow".
The reality is that if I rollback some application/library, one or more features at a higher level may be impacted...
Any ideas?  |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Sat Jun 06, 2015 7:34 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
you need a system in which you can determine outside dependencies.
So your functional release would have dependencies on broker release xyz for app appz...
Your build/deploy / rollback for your functional release would then include a build/deploy / rollback of all the relevant components and dependencies.
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Sun Jun 07, 2015 5:47 am Post subject: Re: Waterfall Code Version Control |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| nelson wrote: |
| Is this a crazy idea? In your experience, source control in broker is managed in an isolated way from the other layers? How can we organize our projects/applications/libraries in broker? |
It's not really a broker problem. If the broker application exposes a web service used by a Java app running higher in the stack, then rolling the broker back (however you've organized the application & it's components in the broker layer) will potentially impact the higher level app.
So you need to take a holistic view, decide how you're going to control & document dependencies between all the components in your stack, and roll them back as underlying components change.
Depending on how you do this, there's no particular reason why broker code can't share source code control with other components.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Jun 08, 2015 5:23 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The really useful thing about a service oriented approach to software design is that the only thing that matters is the interface between two programs.
As long as changing the level of the java code doesn't change the requirements on the interface between it and Broker, then you don't need to worry about rolling back the broker code.
Note that the interface includes both the structure of the data being exchanged and the actual exchange itself - so in a SOAP environment, the WSDL and the security properties and the relationship between a given request and response in terms of timing and lower level response codes and etc. etc. etc.
So if you know that the Java rollback won't affect that, or that the Broker interface will support the older level of the Java messaging, then you don't need to change the Broker.
It's always better to make data exchanges backwards compatible for exactly this reason.
But you still need a larger context to document and manage this level of versioning. |
|
| Back to top |
|
|
| nelson |
| Posted: Mon Jun 08, 2015 2:52 pm Post subject: |
|
|
Partisan
Joined: 02 Oct 2012
Posts: 313
|
Thanks all for your comments.
| mqjeff wrote: |
| It's always better to make data exchanges backwards compatible for exactly this reason. |
This makes a lot of sense to me. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
