Some views on system database and service field upgrade

I am currently in the equivalent of a start-up company.

Work is almost a year, immediately set about preparing for a second trip to upgrade our system, but suddenly think of one thing, let me quite touched, is about the system on-site upgrade.

Our iterative development system will need to go to the user's site for a system upgrade for a period of time, including the client, server, and database.

What are we doing now?

The way to upgrade the service is to completely replace the old service with the new service with the past, and then manually modify the configuration of all the services.

The way to upgrade a database is to deploy a database of the versions we need to upgrade on top of your laptop, and then go to the field and take advantage of the contrast feature of the toad schema (we're using an Oracle database), compare the schemas one by one, and figure out the differences, Manually modify these differences on the user's site database until the two database is the same.

And many times the database modification is for a function, may build triggers, job, sequence, modify the table and so there will be some sequencing, if you do not know these order by contrast to upgrade, the probability of error is very large.

Incidentally, we are the CS system, the changes in the database need to be updated including the table structure modification, metadata table content modification, as well as other such as sequence, stored procedures, triggers, job and other modifications.

Well, I would like to say that the number of services and databases involved in the schema and the number of tables is a little bit better, we can still cope with this, if the service and database schema more?

Then who would not want to travel, the probability of error I feel at least 90%, you have to finish after the site Test 3 days?

Personally, why don't we do it?

1, about the database upgrade

(1) The company's development environment SVN for each system to maintain a system folder, folder for each schema also set up a schema folder, each schema folder contains such documents: "Version X-based database modification", All of them are maintained in the form of SQL script, which records the modification steps of the database and the modified person.

(2) The root directory of the System folder maintains a document, which is the version number of the database schema for the current site, and who is currently scheduled for it.

Just like the following:

On top of that, the next time you're on a business trip, what you have to do is:

View Current User site Schema discovery is version 25,26,26,26, then you go to the respective folder, the corresponding "version 25-based database modification", "version 26-based database modification", "version 26-based database modification", "version 26-based database modification "These files are on the spot, so just run the SQL script in the document in a few clicks."

In the file there are also who made the changes, so you run SQL script when there is any problem can also call back to ask the corresponding responsible person.

Then you return from a business trip, you have upgraded these schemas, so you need to modify the root directory below the document, to be fixed: the corresponding version number +1, and then the revision history to indicate who when the version of the.

Then go to the respective schema folder, create a new document, named "Version x+1-based database modification", for future developers to record the new version of the database modifications made.

Isn't that very convenient?

This method has a principle, can not let anyone have permission to modify the database, or only the project owner to modify the database, and the corresponding record here, or let the person who modifies the database to send SQL script to the project leader or other people to control the database, to record here.

In short, any modifications to the database need to be made clear to those of me who have this mechanism to agree.

2, about the service upgrade

The personal feel that the deployment and upgrade service is the most annoying is the configuration items (our background is useful for WCF services).

If you have to manually modify the configuration entries for each service each time the upgrade service is not obvious.

I think there needs to be a unified place for all the services to be configured, and all the configuration of the entire system will be centrally managed!!!

This requires a configuration center where the entire configuration center maintains configuration information for the entire system.

(1) All services at startup, access the configuration center to get the required configuration items.

(2) on-site deployment personnel can operate the configuration center through a simple UI interface, adding and removing changes to the entire system configuration items.

C # system words may need to implement such a configuration center, pre-can only do a simple node of the configuration center.

Java system, you can use open source zookeeper, which can be used as a cluster to run the configuration center.

The above is entirely the feeling of an individual who has worked in such a company for almost a year, feeling some bad places and then presenting some of his own ideas.

My idea may not be very reasonable, it needs to communicate with the more mature company people to know.

Hope that if you look after the idea and similar experience, the generous enlighten, my little brother here thanked!!!!