H
hutcj
Guest
There is a strong push to accelerate the testing and deployment of databases to keep up with the agility of source code. However, it is not a simple thing because of the nature of databases. For example, perhaps bugs from previous versions allowed bad data into the db that must be corrected; or data must be migrated to fit new models; or care must be taken to ensure data is not lost when promoting new schema (particularly renames). Not to mention updating all code which accesses the db, including triggers. It goes without question that the database should be under the same rigorous version control that the source code is. Since the incremental df files needed to migrate the production database to the new schema is more a deployment detail than anything, I initially assumed the state approach, i.e. dumping the full schema and version controlling that, would make the most sense. However, this runs into problems at deploy time because the context for the change has been lost. On the other hand, version controlling an initial schema and an ever-increasing number of migration scripts (incremental df's) would (I think) cause performance issues with CI as test db's must be regularly built and torn down. Also, we would still need the full schema file in order to have the pipeline analyze it for problems. How do you handle this problem? Keep both the full schema and migration scripts (both for schema & data) in source control? Some kind of hybrid approach with full schema and rename files?
Continue reading...
Continue reading...