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

Larry O'Leary loleary at redhat.com
Wed Feb 17 12:38:00 EST 2010


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/



More information about the teiid-designer-dev mailing list