A better approach of retaining data between builds

It takes a big man to admit his mistakes. Not that I am that big with the exception of my ego :)

This is a retraction of a previous blog article I wrote regarding retaining data between builds. After running through the process I found a critical flaw in the approach: Failures are only detected on deploy. Having the failures detected at a later time makes things harder to fix as shown in this graph: So we should push the failures early on. The best way of doing that while retaining the data is to use the DMX files. Curam provides a build target called extractdata which allows you extract data from tables and converts them into DMX files. These DMX files can be copied over to the proper Data_Manager directory. The list of tables to convert are stored as a batch file that invokes build extractdata for each table that needs to be converted and have the files copied to the proper directory. These DMX and batch files are version controlled per environment and are used as part of the build scripts. Since they are now a part of the build, validations on the data such as missing or extra tables, columns or rows are detected during the build process. Integrating with the build process is a matter of putting in additional build database commands during the continuous build process with different targets. You need set the prm.target system property using -Dprm.target=environmentName on the build database command line to specify the proper target. When the build database gets executed during the build, it will fail if there are any missing or additional structures. This allows the developer to make the necessary fixes on the DMX files as needed and can be run to reset the proper environment later. So to re-iterate, do not use the previous approach I had mentioned. Use this one instead as failing earlier makes the cost of fixing it lower.