Recently conducted a major upgrade of the system, because the database upgrade script to be executed by a lot, so when released accidentally execute a script should not be executed. Afterwards though we were promptly remedy, but
Still the system of business stagnated for nearly two hours.
It is necessary for the registration and release process management and database scripts database scripts to sort out next.
First of all reflected in the registration database script:
1. script registration must be registered in accordance with the project a unified folder, the folder name to be named in accordance with uniform standards, so that one will be able to distinguish who published under the name of the folder.
Because we are usually a number of projects in parallel, though they are around during the development of a product, but the start and end of the project is a sequential, it is generally a project
The script should be in a folder, and because the project is carried out in an iterative, not all features will be once it is released over, so be sure to lower the project folder and then there are sub-text
Clip to distinguish, for example, is developing a script that some functions are not into the PRD database, so we should have two files in the project folder, it is a development and test use
Another is designed to be used when publishing PRD. Each release will feature former PRD determine released, so that we can compile a script from the development and testing of folders
For publishing.
2. Each registration must be clearly written script and illustrate the use of this script, creator, time of registration, the implementation of those databases, if there are precautions you need to be explained, such as this script
Only in the database to perform or not perform at the library. While common database scripts and stored procedures and functions to be registered separately in a different script file. Meanwhile registration script
Achieve incremental register, that is, if you modify a stored procedure, please modify the stored procedure directly registered in the registration dedicated to the stored procedure script file, do not modify previously registered storage
process.
The second is the process of launching our database the script:
1. Each time PRD version will be released, the script needs to be published in advance and publish the project to be confirmed by beta clear, because also released a beta version of the project will be very clear test version
The implementation of the script, but also recorded, so you can ensure execution of the script have already passed the test, so that it can ensure the proper execution of the script when you publish.
2. If you are experiencing major version upgrade, the day before the system upgrade, or half a day, acquire a new official version of the backup, do a simulation upgrade, the problems you might encounter as exposed,
This can further reduce risk.
3. Before database upgrade script execution, as do first backup, then execute.
Another point to note is that conflict.
Since we for the same product in the case of parallel development of multiple projects, so there will be as AppID, MenuID, ID and other basic items, such as OrderTypeID that require new, this time
To ensure the ID or primary key violation does not occur when we execute the script that we want to write these scripts are in a global database to occupying, first to occupy this position ID, and then
Registration, so it will not happen this way.
Reproduced in: https: //www.cnblogs.com/kevinGao/archive/2012/12/15/2819710.html