Continuous integration and version control database
- Abstract: The purpose version of the database is to be able to ensure that changes made to maintain consistency, controllability, testability and reproducibility. Database version 2.0 is in accordance with the baseline installation script, the script must be applied 02.00.0003, but the actual product database from version 1.0 may be the beginning, it will apply the 01.00.0046 script to fix, so you can not let go 02.00.0003 the actual modification has been upgraded to version 2.0 of the database again. otherwise, it will cause an error.
- Tags: database integrated version control
After the proposed version of the database work is a necessary rule this view, Scott Allen and detailed version of the method a good database, he gives an easy to understand, very practical method, by creating baselines, use the method of changing the script to manage database revision, the control program of the database object (e.g., views, stored procedures, functions, and triggers), and the full use of branching and merging.
Allen after the release of the lessons learned article three principles of relational database development, he began to write a series of follow-up article. These three principles are as follows:
First, do not carry out development work on a shared database server
Like other so-called easy software development methods, like the use of a shared database is a quagmire, it is waiting for a project to freeze it. Developers mutual cover the modifications made to each other, I'm changes made on the server so that the code on your development machine interrupt the operation, which are so remote development speed is very slow and very difficult. Avoid using shared database, also free to avoid the extreme waste of time due to the use of its cause and consequent born Bug.
Second, retaining only an authoritative source of Schema generation
Everyone must know where to get official Schema, and you can use it to easily re-create a new database. When I went to the computer before, you can get the latest version from source library, constructed after the database can be created through the most simple tools (in more scenes in the build process can even create a database does not exist at the time of their own, so this should be a one-step process of building the way).
Third, your database version management
One reason for this is that you want to change delivered by development to testing, final production in a controlled and consistent environment. The second is that we can rebuild the database on any point in time, if you are a software delivered to the customer, then it is particularly important. If someone found a bug in the version of the application you submit build in 20,070,612, then you must be able to re-establish the situation that version - including data and other needs.
Allen explains the purpose version of the database is to be able to ensure that changes made to maintain consistency, controllability, testability and reproducibility. Many promoters agree on this point, and that to achieve this goal is important for the efficiency of any agile team.
In the list of importance versions of the database after, Allen and have released four posts to describe his recommendation implementation.
Among them, the first chapter describes the post starting point versioning database of Allen claims - create a database Schema baseline. In essence, this baseline is a script or series of scripts that contains all application database from scratch generated SQL commands. It includes all of creating a database of all objects (tables, constraints, functions, view, index, etc.) of the SQL command, table query command and operation command, and insert the initial data required by the application. Allen suggested that once it completes creation and verification, should immediately "to submit it to the source control repository" where "you can think of have a baseline database."
How to create this baseline, Allen is recommended to use those tools to export scripts from existing databases (and their opposite hand-written procedure). As a reference, he also describes how he structured those generated script file:
I like to generate all the tables, constraints, defaults, and save the primary key SQL statements to the same file, create a script and those views, stored procedures, functions is separately stored separately.
If you like to save more papers, it would need a batch file, shell scripts, applications, or other automation tools to automatically locate and run all the scripts install the database needed. Human intervention process is a step backward.
Allen recommendations and stressed the need for a baseline table is used to record any changes related to database structures, three behind him in the post, he describes in detail how to deal with these changes.
First of all, Allen discussed the change script - a mechanism for managing database objects except views, stored procedures, functions of the. This method requires any change (or a group of related changes) must have a new generation of script files can be represented by way of "incremental" update, which is very similar to Ruby Migration. In other words, when the team found that the database needs to be done to change, they create a new script to modify the database to look like you want to submit to source control through the library after the test. Once released, the script would never again be modified.
Allen doing so view, update stored procedures and functions with other database objects exactly the opposite, each object has a "Create command" file, and then to update these objects by updating this file, for why he likes to do so, he explains:
The reason is simple, is to identify the problem more quickly. If someone submits a database structure changes, it removes a column referenced by the view, you can see errors as early as possible, because in the build submitted to the test before, this problem will be found; Similarly, if someone commits a view, but forgot to publish it needs structural changes, a few minutes later someone will ask them to go to the front desk why they destroy the software is running.
Another reason is to avoid some of the less common mistakes I've ever met. Schema changes for those hidden behind the view, some database products will still be forced to complete the implementation plan, and the problems caused difficult to trace. "Throw away everything, re-start" will prevent this sort of thing.
Allen stressed the importance of using automated tools to better implementation of the above strategy:
When developers, testers or installer updates from source control repository and run the local data upgrade tool, as it will magically work done. It has three steps:
1, the script file and by recording the comparison table SchemaChangeLog database structure change prior to application of the latest database structure;
2, delete all the stored procedures in the database, and view function;
3, run all the view changing script, stored procedures and functions added back to the database.
For the benefit of following these policies, particularly the use of automated tools, Allen gives some examples:
Since the data structure change script is saved in the source control repository, you can re-create the database on any point at any time. If a customer reports a build 3.1.5.6723 about the bug, then you need to do is get the appropriate version of the source label or labeled, and then run the baseline and mark all the database change scripts. After the end of its run, and you've got a bug when customers find exactly the same database, this bug will get a good chance to reproduce. Moreover, when changing the testing stage of development, it provides a consistent, orderly, reproducible product fundamentally.
Allen In the last article of this series, also mentioned how he handle branching and merging, and this is the real problem after all applications to establish its first version must face on the server version. Allen and recommendations for release branch, which is a branch of his policy preferences, while explaining why he hit a baseline database for each new release. He is described by an example of this problem, and added such a scenario: find a flaw in earlier versions, you must make the appropriate changes to the structure of the data structure has branched version. In this branch version, create a new script to handle the change is not a problem, the question is, how will this change also applies to the current mainline release:
Want to fix it in the main line, there are two options. In fact there may be a myriad of possibilities, depending on how you want to apply your updates. But here only two options:
1, the database change script into the current script mainline 01.00.0046, the repair and the corresponding version 2.0 at baseline to deal with this change;
2, write a new database structure change script 02.00.0003, with branch version 46 changes consistent.
For Option 1, you have to be careful, because any has been updated to v2.0 version of the database will not get No. 46 to change the script (unless you're writing tool and I are not the same) from the branch. You can let other people run this script manually, or your own view of the existing version 2.0 database conflict (for this result, in any case limited to the development and testing of the machine). So, unless you have just begun to develop shortly 2.0, otherwise the selection is not very good.
By contrast, Option 2 will have more than a friendship. 1.0 version of the database will be obtained from the restoration of 01.00.0046. 2.0 version of the database is to be fixed in the 02.00.0003. But you have to be very careful to write scripts to modify 02.00.0003, the changes made after the covers over it so as not to run the 01.00.0046 script.
In other words, the database is in accordance with the version 2.0 baseline scripts installed, the script must be applied 02.00.0003, but the actual product database from version 1.0 may be the beginning, it will apply the 01.00.0046 script to fix, so you can not let 02.00.0003 to amend this actually has been upgraded to version 2.0 of the database again. otherwise, it will cause an error.
Reproduced in: https: //www.cnblogs.com/kevinGao/archive/2013/01/24/2922931.html