[teiid-dev] [teiid-designer-dev] VDB Versioning Feature

[Steven Hawkins]

At first glance in the scenario you list below, there's no need to even bother with the promotion concept.  You would just install the new version (with a new name) and let apps point over to it as they are ready.  

To achieve the flow your suggesting without versioning would actually require an extra step.  Prior to promoting the next version, you would need to deploy a duplicate of the current version with a new name.  Then the small set of apps not ready for the update would need to have their connections pointed to the copy.  Then you could safely promote the next version without interrupting the lagging apps.

----- Original Message -----
From: "Larry O'Leary" <loleary at redhat.com>
To: "John Verhaeg" <jverhaeg at redhat.com>
Cc: "teiid-designer-dev" <teiid-designer-dev at lists.jboss.org>, "teiid-dev" <teiid-dev at lists.jboss.org>
Sent: Wednesday, February 17, 2010 11:38:00 AM GMT -06:00 US/Canada Central
Subject: Re: [teiid-designer-dev] [teiid-dev]  VDB Versioning Feature

On Wed, 2010-02-17 at 11:27 -0600, John Verhaeg wrote:
> On Feb 17, 2010, at 10:44 AM, Larry O'Leary wrote:
> 
> > Well there are two possibilities here.  One is that there is a
> > roll-back.  The other is that a new version of a VDB has been chosen as
> > the default but some of the organization is not ready to use the newer
> > version.  In which case they would modify their clients to use the
> > previous version until they are ready to use the new one.  
> > 
> > So, in the "roll-back" scenario, the change is transparent to the
> > clients while in the "not-ready-to-upgrade" scenario the administrative
> > change is placed on the client.  These are the two cases we have with
> > legacy customers.
> 
> Maybe I'm misunderstanding, but I don't believe your "new version"
> scenario makes practical sense.  If an organization is implementing a
> new version and not ready to force that change on certain
> applications, departments, etc., wouldn't they want just that - no
> change to those areas?  They're likely not going to impose the need to
> change a slew of existing clients to use the old VDB just to enable
> new clients to use the previous VDB name.  Rather, they'd want to
> deploy the new VDB with a new name that only the new clients use.
> Then migration to the new VDB name for other clients could be easily
> scheduled and managed.  Seems like the alternative would be a
> change-control nightmare.
> 

Here is how it works.  All clients are using an existing VDB and
development creates a new version of that VDB.  They put it through all
the testing and identify any possible conflicts and changes that a
client may need to make.  The VDB is then slated to be migrated to
production during their quarterly maintenance window.  However, a small
group within the organization have not been able to complete all of
their testing necessary to use the new version of the VDB.  In this
case, a business decision is made to proceed with the migration into
production and the "small group" is notified that they have until MM/dd
to complete their testing or they will need to point their clients at an
old version of the VDB.  The old version will be left in production but
as a deprecated source.
--

Larry O'Leary
Middleware Support Engineering Group
Global Support Services
Red Hat, Inc.
loleary at redhat.com
1.866.LINUX70 (+1.314.336.2990) xt 81-62909
Office: +1.314.336.2909
Mobile: +1.618.420.7623
--
Looking to carve out IT costs?
http://www.redhat.com/carveoutcosts/

_______________________________________________
teiid-designer-dev mailing list
teiid-designer-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-designer-dev