"Partial version part of module update (on line)" of ASP.

Project development is never a simple question. The more difficult issue is to maintain projects that others have developed and to modify bugs. Refactoring is required if there are major problems with the original system.

How to reconstruct the system is not the problem discussed in this paper, but how to deploy it after reconstruction is closely related to this article. This everyone may just be interested.

To get to the chase, now demo if you do part of the version and part of the module update.

ASP. NET Modular Development Series Catalog

1. asp (source code) for the MVC partition expansion framework

2. "Open sub-module development simple and enjoyable journey" of ASP.

3, "logic (Project) reuse" of ASP.

3.1. Logical (Project) multiplexing of different roles or permissions (application of partition filters)

3.2. Logical (Project) multiplexing of different businesses (DI (Dependency injection) applications)

4. "Project (partition) split" of ASP.

5. "Partial version part of module update (on line)" of ASP.

One, now assume a system architecture

The above is a simple site of the architecture diagram
The actual development is three projects, blog (blog), News and Comments (coment)
which commented on the project (partition) deployed two,/blog/coment/and/news/coment/

Second, now we have new needs to review the function of the upgrade

1, we split the review function version

Original version: \branchs\coment_v1.0

New version: \branchs\coment_v1.1

2, fortunately our great programmer efficiency is high, rinsed, the new version is completed, to deploy the

But for various reasons, the leader updated blog comments (/blog/coment/), to blog comments on the line after a period of stability and then update news comments, then we how to do?

And we're going to give you a quick fallback if there's a problem with the new Comment feature (to make a fallback plan)

Three, well, although the demand is a bit "abnormal", we can not say we can't do it

Here's an aside, the paranoid group of programmers is the last to tolerate the ability of others to question themselves. In fact, programmers are also people, not omnipotent. It cannot be done properly or no.

Direct:

1. Add a single site to the backend (tmp.xxx.com)

It deploys a partition/blog/coment/

2, front-end (Ngnix) configuration A rewrite rule points to this section of the new site

This new feature will be on the line, happy, and the access path has not changed, other related modules directly connected to the need not be modified. To degrees Niang and other search engines are not any impact.

The old site (IIS) We did not make any changes, the original is normal now the likelihood of abnormal is very small, reduce the risk of online.

One might say that the new Comment feature modifies the table structure, and even if the source IIS site is not updated, the old comment site may be dead. I can only say, you have to be so reckless I can't.

This requires a well-written modular code, before upgrading to consider compatible with the original data structure, different services as far as possible to split the table. If possible, do not modify the original table structure when upgrading, but create a new table, import the historical data into the new table before you go online, and then chase the incremental data after it is fully online. According to their own team's technical strength and product demand, how much can be done.

3. What should I do if I return? (Fallback scenario)

Haha, this is more simple. Just remove the newly added rewrite rule from the Ngnix.

4, someone may say, you this unscientific, modified blog comments probably blog module also needs to be modified

Indeed, modifying the blog Comment Blog module may also need to be modified on-line

Go on:

This figure is a local diagram, the original IIS site deployment or unchanged

5, some people say, our company does not Ngnix, you this request is too high

In fact, other front-end have rewrite function, Apache and so on.

Some have no front end is not very good to run. But the front-end is really a Web site standard, in front of the log, cache, compression, protection and so on. To make a Web site run better and faster, you need to make it as small as possible (essential business processing).

6, some people say you this is not enough science, we can split into 4 separate IIS sites

Split into 4 IIS sites is a scenario that can be better isolated to reduce mutual impact

But this premise is worth dismantling, such as performance to bottleneck, single business (partition) traffic is too large, many different teams maintain different business (partition).

To know that maintaining a person to maintain a site and 4 sites is not the same, the same code you need to deploy to 4 different places. In reality, we will develop countless products (business), some products are very small, but can not go offline. Why the small flow of products can not be offline is not the scope of this article, it is not expanded here.

7, some people will say you this increase of the TMP site is what ghosts, is to exist forever?

This is called the TMP is only for example, in reality with other names is also possible, the temporary version of all the combined can be all the latest version of the site to update or back to the original site can be.

This usage can be called "AB version", sometimes with a version, sometimes with the B version, sometimes the AB version coexistence (need to note in the maintenance document which features on which version of the site).

If the demand conflict is particularly serious, then a C version or D version of the temporary site and what is not possible? The most important thing is to solve the real problem. Can't always wait for everyone to merge the version and go live together. Is it more efficient to have many updates that are properly present in multiple versions?

"Partial version part of module update (on line)" of ASP.