What is the CI/CD model for this capability

[cb11]

We are trying to understand with respect to Teiid and Data  Virtualization the best approach that will provide us with closest approximation of Continuous Improvement and Continuous Deployment for our Virtual Databases.  Is there a hot and cold deployment model that we need to consider and if so what does that model look like?

[rareddy]

I am trying to understand your development model for building the virtual databases? How are you coordinating between multiple developers? Currently if you are using a DDL based Dynamic VDB, that model can be used with any source control repository, which can then be designed for continuous deployment. If you are using the Designer based VDB, the merging changes between multiple users can be challenging. There you have to use "checkout and lock for edit" model.

JBoss DV offers script based deployment for VDBs, which can be used for deploying to server. Internally, we also Arquillian based integration tests for verification of functionality.

I suggest, that you think of JDV just like any other database for development process, then follow your internal policies, then we can see if DV offers solutions to fits the model.

[cb11]

Thanks for your response.

At this time we don't have a development model for building virtual databases.  Still trying to get through a couple of database connection issues that are holding us back from really demonstrate tangible results with VDBs.  We aren't far enough along to know whether to use static or dynamic VDB approaches and why one or the other works.  Are you recommending us not to use Teiid for creating VDBs? 

Assumption is that we are supporting self service models where the source databases will change often and quickly and we will need to respond even faster to sync up the dependencies.  For ease of consumption we are hoping to have one parent VDB supported by many child vdb.  I foresee many teams creating their own virtual databases that will be children/schema presented by parent enterprise VDB for ease of consumption, one connection.  Change would be a constant and requirement is the change could take place without interrupting connected users, seemless.

As enterprise virtual database can be conceived more as "middle" layer its hard for us to conceptualize how it can be same with building normal database solution.  Still hoping some content for baseline development and ci/cd model with hot and cold deploy methods included can be found.  I don't want to assume that our internal development processes are consistent nor that we couldn't learn from the community on how to do something better or where we have limited ourselves based on the internal processes we have in place.

hoping this gives you a better sense of what we are looking for so that we can get a better recommendation.

[rareddy]

Are you recommending us not to use Teiid for creating VDBs?

You mean Teiid Designer? No I am not saying that, I am highlighting what would be the complications in using one Dynamic Vs Designer based VDBs for continuous development model.

Assumption is that we are supporting self service models where the source databases will change often and quickly and we will need to respond even faster to sync up the dependencies.  For ease of consumption we are hoping to have one parent VDB supported by many child vdb.  I foresee many teams creating their own virtual databases that will be children/schema presented by parent enterprise VDB for ease of consumption, one connection.  Change would be a constant and requirement is the change could take place without interrupting connected users, seemless.

If I am understanding this correctly, your child VDBs are changing constantly, but your enterprise VDB is layout over your enterprise data sources and will give single point of access. As long as each time you modify a deployed VDB, it is deployed with a newer version of the VDB, then the connected users will not be affected. Any new user connections can be directed specifically to either older VDB or newer VDB based on your preference, such once all the users sessions are closed the VDB can be retired.

As enterprise virtual database can be conceived more as "middle" layer its hard for us to conceptualize how it can be same with building normal database solution. 

Even though this is middle layer, the end user application written on top do know this layer any differently than traditional databases. Rather thinking like middle layer, think more like consolidation of your enterprise data layer. Then each of your child VDBs are logical layers that closely resemble the business layer they were being written to. Then VDB contains the views to convert the logical views to physical ones.

Still hoping some content for baseline development and ci/cd model with hot and cold deploy methods included can be found.  I don't want to assume that our internal development processes are consistent nor that we couldn't learn from the community on how to do something better or where we have limited ourselves based on the internal processes we have in place.

I was hoping other folks from community chime in on this with their experiences.

Typically the VDB & models are put in a source control repository for sharing across team members, and from there either scripts or manual deployments methods are used for deployment of those VDBs. Since there is no additional building on top of the VDB, the artifacts are tested with client application specific usecases. Also note VDBs are not changing continuously after the initial deployment, they are only modified when there are changes from client application or data sources. DV does support hot or cold deploys.

hoping this gives you a better sense of what we are looking for so that we can get a better recommendation.

Sorry, couldn't be more help. If you have specific question about individual steps, I would gladly help you.