"PM" Some views on system database and service field upgrade

Work nearly 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 right now?

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

The way to upgrade a database is. Deploy a database of version numbers that we need to upgrade on top of your own notebooks. Then go to the scene and take advantage of the Toad Schema's control function (we're using an Oracle database). Compare the schemas one by one, and then find out the differences. Manually change these differences on the user's site database until the two database is the same.

And very often the database changes are for a function, there may be a trigger, job, sequence, change table and so there will be some sequencing, assuming that the order is not known by contrast to upgrade. The probability of an error is very large.

Incidentally, we are the CS system. Changes that need to be updated in the database include table structure changes. Changes to the contents of the metadata table, as well as other changes such as sequences, stored procedures, triggers, job, etc.

All right. I would like to say that the number of services and the database 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 no one wants to go on a business trip. The probability of error I feel at least more than 90%, you have to finish after the site Test 3 days?

Personally think, why don't we do it?

1, about the database upgrade

(1) The company's development environment SVN maintains a system directory for each system. A schema directory is also created for each schema in the directory. These documents are included in each schema directory: "Database churn based on version number X". All of them are maintained in the form of SQL scripts, documenting the changes and moving of the database.

(2) The root folder of the system folder below maintains a document, which is the version of the database schema for the current site, and who is currently at what time for its revision.

Just like this:

On this basis. Assuming you're on a business trip next time, all you have to do is:

View the schema discovery for the current user site, each of which is version number 25,26,26,26. Then you go to the respective directory below. The corresponding "database churn based on version number 25", "Database churn based on version number 26", "Database churn based on version number 26". "Database churn based on version number 26" These files are on the spot, so you just need to run the SQL script in the document in turn.

The file in the face and who made the changes, so you run the 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 change the root folder of the following documents, to be fixed: the corresponding version +1, and then the revision history to indicate who when the version of the.

Then go to the respective schema directory below and create a new document. Named "Database churn based on version number X+1". For future developers to record the database changes made above the new version number.

Isn't it very convenient?

This approach has a principle that no matter who has the right to change the database, or only the project owner to change the database, and the corresponding record here, or let the person who changed the database to send SQL script to the project leader or other people to control the database. To be recorded here.

Anyway. No matter what the database changes. I need someone who is clear about my mechanism to allow it.

2, about the service upgrade

Personally, the most annoying thing about deploying and upgrading services is the configuration item (our backend utility is the WCF service).

Assuming that each upgrade service has to manually change the configuration entries for each service, it is not obvious.

I think there needs to be a unified place to do all the service configuration, will be the entire system configuration for centralized management!!!

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

(1) All services at startup, visit 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 deleting the configuration items of the whole system.

C # Systems may need to implement a configuration center of its own, the early can only do a simple node configuration center.

Java System. The ability to use open source zookeeper. Be able to execute the configuration center as a cluster.

These are all the feelings of individuals who have been working in such a company for almost a year, feeling some bad places. Then put forward some of their own ideas.

My idea may not be very reasonable, and it needs to be communicated with people in a more mature company.

I hope you have seen some ideas and similar experiences after reading the advice. My little brother thanked me here.

！！

"PM" Some views on system database and service field upgrade