Hi there,
So I have two problems actually that any recommendation are more then welcome.
Problem 1
Our environment is laid out like so. We have three sandboxes per project; QA, UAT and Live. We develop into the QA sandbox, replicate onto UAT (which is an exact mirror of live conf wise and scheduler wise). Wait for client sign off then replicate UAT onto live. This is all done on the same Clover server. One nice thing would be if I could have a simple way of dealing with this. At the moment I use Clover ETL designer "Export to sandbox" which works fine, however it is a bit cumbersome as I have to uncheck a bunch of things. Data-tmp, data-out etc. It would be nice if every night clover schedular could replicate from QA to Live (even using Clover ETL to do so :S). Any ideas?
Problem 2
This sort of stems from the above workflow. Each client can have multiple ETL environments (version 4.0, version 4.1, version 4.2 etc) each comes with its own ETL package (three tier QA, UAT, Live). Now here's the problem, if I fix an issue in the ETL 4.0 branch, that means it would have to be applied to 4.1 and 4.2. However 4.1 & 4.2 could have active development so copying and overwriting the graph/jobflow file is out of the option as other members of the team would have their work wiped out.
One option was backing everything with SVN however what would happen in the instance of merge errors. I remember backing everything with SVN at the start of our clover investmentwhile somewhat good, there where a lot of conflicts front, left and center and having to resolve in source XML was not fun. Eventually I had to drop SVN as it does not work with Clover Server ether. We are in need of a method to forward merge from 4.0 to 4.1 but not backwards. So fixes in 4.0 would be applied (as once the client signs off live a new fork is made, in this instance a 4.2 would be made and 4.1 would be in maintenance and 4.0 would be archived).
Any recommendations are greatly appreciated,
Cheers
Jack :)
So I have two problems actually that any recommendation are more then welcome.
Problem 1
Our environment is laid out like so. We have three sandboxes per project; QA, UAT and Live. We develop into the QA sandbox, replicate onto UAT (which is an exact mirror of live conf wise and scheduler wise). Wait for client sign off then replicate UAT onto live. This is all done on the same Clover server. One nice thing would be if I could have a simple way of dealing with this. At the moment I use Clover ETL designer "Export to sandbox" which works fine, however it is a bit cumbersome as I have to uncheck a bunch of things. Data-tmp, data-out etc. It would be nice if every night clover schedular could replicate from QA to Live (even using Clover ETL to do so :S). Any ideas?
Problem 2
This sort of stems from the above workflow. Each client can have multiple ETL environments (version 4.0, version 4.1, version 4.2 etc) each comes with its own ETL package (three tier QA, UAT, Live). Now here's the problem, if I fix an issue in the ETL 4.0 branch, that means it would have to be applied to 4.1 and 4.2. However 4.1 & 4.2 could have active development so copying and overwriting the graph/jobflow file is out of the option as other members of the team would have their work wiped out.
One option was backing everything with SVN however what would happen in the instance of merge errors. I remember backing everything with SVN at the start of our clover investmentwhile somewhat good, there where a lot of conflicts front, left and center and having to resolve in source XML was not fun. Eventually I had to drop SVN as it does not work with Clover Server ether. We are in need of a method to forward merge from 4.0 to 4.1 but not backwards. So fixes in 4.0 would be applied (as once the client signs off live a new fork is made, in this instance a 4.2 would be made and 4.1 would be in maintenance and 4.0 would be archived).
Any recommendations are greatly appreciated,
Cheers
Jack :)
-
Hi Jack,
Problem 1:
ETL graph is a regular file like any other. Therefore you may simply create a graph that will copy/move these files anywhere you want – in your case to Live sandbox directory. Such a graph can be triggered like any other graph periodically using a scheduled task.
Problem 2:
Although it is not directly supported, the most suitable would probably be to use SVN in this case. In order to use SVN for Server projects you will need to maintain local copies of server sandbox projects, since versioning systems do not directly support remotely stored files. -
We released a new milestone version of CloverETL a few days ago. Version 4.2.0-M1 contains a new feature for connecting CloverETL Server projects to your versioning tools.
For more details, see http://www.cloveretl.com/resources/releases/4-2-0-M1
However, let me remind you that milestone versions of CloverETL serve only for showcase purposes and we strongly do not recommend to use them in production environment.
Please sign in to leave a comment.
Comments 2