Continuous database integration and Version Control [from infoq]

Allen's experience in releasing three principles for Relational Database DevelopmentArticleThen, I began to write a series of subsequent articles. The three principles are as follows:

1. Do not develop on the shared database server

Just like other so-called convenient methods in software development, the use of shared databases is also a quagmire, And it is waiting to freeze a project. Developers overwrite the changes made by each other. The changes I made on the server allowCodeInterrupted operation, which makes remote development very slow and difficult. Avoid using a shared database, and avoid extreme time waste and bugs caused by using it.

II,Retain only one authoritative schema Source

Everyone must know where to obtain the formal schema and use it to easily create a new database. When I go to the computer, I can get the latest version from the source code library. After the build, I can use the simplest tool to create a database (in more scenarios, the building process can even create one if the database does not exist, so the building process should be one-step ).

3. Manage Your database versions

One of the reasons for doing so is to pass the changes from development to testing and ultimately produce in a controllable and consistent environment. Second, you can rebuild the database at any point in time. This is especially important if you are delivering the software to the customer. If someone finds a bug in the application version build 20070612 you submitted, you must be able to reconstruct the current version-including data and other requirements.