单个代码库多个网站 [英] Single Codebase multiple websites

查看:38
本文介绍了单个代码库多个网站的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们开发了一个使用单一代码库的系统,由四个带有管理网站和面向客户的网站的 Visual Studio 项目组成(每个系统都有自己的 MS SQL 数据库).

We have developed a system that uses a single code base, consisting of four Visual Studio projects with an admin website, and customer facing website (each system has its own MS SQL database).

这一直很有效,因为所有新网站(包括管理员)都从 SVN 中引用相同的代码库项目,因此对代码库所做的任何更改都可用于所有网站.

This has been working great, as all new websites (including admin) reference the same code base projects from within SVN, therefore any changes made to the code base are then available to all websites.

每个网站都有不同的母版页和不同的用户控件 (.ascx),因此虽然网站背后的主要编码相同,但部分不同.

Each website has a different master page, and different user controls (.ascx), and therefore partially different although the main coding behind the sites is the same.

我们现在遇到的问题是,如果有错误、功能更改或新功能,我们必须分别在所有站点(对于管理员站点和客户站点)中实施它.这开始让我们发疯,也意味着我们在实施这些更改时存在巨大的误差.

The issue we are having now is if there is a bug, a feature change or a new feature we have to implement it in ALL the sites separately (for both admin and customer site). Which is starting to drive us insane, and also means we have a HUGE margin of error for implementing the changes.

我曾考虑使用 svn:externals 但这会变得混乱.

I have thought about using svn:externals but this will become messy.

从主网站和主管理系统分支可能是一种选择,但合并以获取新代码是一个主要问题,因为站点不完全相同.

Branching from a master website and master admin system could be the option, but merging to get the new code is a major issue with the sites not being exactly the same.

我认为一个很好的概述是每个站点的标记完全不同(管理站点除外,这只是一个主题更改)但代码库是相同的.

I think a nice overview would be say that the markup is totally different per site (except the admin site, which is just a theme change) but the code bases are the same.

管理此问题的最佳方法是什么,还是我们一直在进行大量复制和粘贴?

What is the best way to manage this or are we stuck doing a lot of copy and paste?

您希望明确哪些要点?

出现的问题包括页面 JavaScript 不同,网站之间的 HTML 布局可能完全不同.但是页面的代码是一样的.

Issues that arise are such as in page JavaScript being different, HTML layouts can be completely different bewtween websites. But the code for the pages is the same.

所以我需要同步"在 app_code 中找到的文件和文件夹,但这里也存在问题.

So I would need to 'synchronise' file and folder such as those found in app_code, but there are issues here as well.

站点 1 和站点 2 可能完全相同,只是主题不同.站点 3 也有一个不同的主题,但它也有一些定制的代码,只有这个站点才需要,app_code 中的一些代码也与站点 1 和站点 2 的行为不同

Site 1 and Site 2 could be exactly the same, just a different theme. Site 3 has a different theme as well, but it also has some bespoke code that is only required by this site, some of the code in app_code also acts differently to Site 1 and Site 2

现在我可以通过分支轻松实现这一点,但是当合并到新分支时,如果存在代码差异,那么就会出现重大冲突.

Now I could easily achieve this with branching, but when merging up to the new branches, if there are code differences then there are going to be major conflicts.

合并也将成为一项大任务并且需要很长时间,因为我们只需要合并某些文件夹和文件,尽管您不能通过分支合并单个文件(这可能是错误的).

Merging would also become a large task and take too long, as we would need to merge only certain folders and files, although you cannot merge a single file through the branch (this could be wrong).

例如:

在根目录中有一个 download.aspx,它返回一个流作为响应而不是一个页面,它用于通过系统推送所有下载请求.

In the root there is a download.aspx which returns a stream as the response rather than a page, this is used to push all the download requests through the system.

所以站点 1 和站点 2 中的这个页面是相同的,但在站点 3 中它做了一些其他站点不需要或不需要的额外功能.

So this page in Site 1 and Site 2 is the same, but in Site 3 it does something extra which no other site requires or needs.

我们不希望此定制功能成为过载,因为我们不希望/需要其他网站使用它,我们现在无法再从主网站合并此文件,必须手动合并.

We don't want this bespoke feature to be an overload as we don't want/need it for the other websites, we can now no longer merge this file, from the master website, it must be manually merged.

希望这能更好地解释我想要实现的目标.

Hope this explains better what I am trying to achieve.

网站基本结构

|- App_code
|- App_Themes
|- Bin
|- Content
|     |- Flash
|     |- Images
|     |- Scripts
|     |- Uploaded
|
|- Controls
|     |- MasterPage
|     |     |-MasterPageControls
|     |
|     |- Navigation
|     |- Search
|     |- Templates
|     |     |- Control Templates 
|     |     |- Page Templates
|     |
|     |- WebServices
|     
|- Errors
|

控件导航、搜索、模板下的所有内容都是 .ascx 文件.

Everything under Controls Navigation, Search, Templates is .ascx files.

根目录下有几个文件,包括default.aspx、download.aspx和preview.aspx

In the root there are several files including default.aspx, download.aspx and preview.aspx

这些是网站的主要页面(忽略错误页面),所有页面都是从数据库动态创建的.

These are the main pages for the website (ignoring Error pages), all pages are dynamically created from the DB.

Controls 文件夹是网站之间大部分更改发生在 MasterPage 和所有其他用户控件中的地方.

The Controls folder is where most of the changes between websites happens in the MasterPage, and all other user controls.

推荐答案

几个月前,当我们开始对我们的 Web 应用程序进行重大重写时,我遇到了这个确切的问题.我们有两个不同版本的几乎相同的网站.后端代码 99% 相同,而 JavaScript、CSS 和其他前端代码则大不相同.我们将这两个站点放在同一个 SVN 存储库的不同主干中,很快就变成了复制和复制的噩梦.在它们之间粘贴公共代码.由于文件中的细微变化,修补和合并太痛苦而无用.

I ran into this exact problem a few months ago when we started a significant rewrite of our web app. We had two separate versions of nearly identical sites. The back-end code was 99% identical, while the JavaScript, CSS, and other front-end stuff was very different. We had these two sites in separate trunks in the same SVN repository, and it soon became a nightmare of copying & pasting common code between them. Patching and merging was too painful to be useful, due to slight variations in the files.

我们的解决方案既不与 SVN 相关,也不构建通用库.相反,单独站点的概念是通过多个配置文件和 CSS、图像和语言资源文件的层次结构在单个代码库中定义的.特定于站点的功能由配置值启用.

Our solution was neither SVN-related nor builing of a common library. Instead, the concept of a separate site is defined in a single codebase via multiple config files and a heirarchy of CSS, image, and language resource files. Site-specific features are enabled by config values.

每个站点都有一个唯一的名称(例如foo"和bar"),该名称是在运行时从 Web.config 文件中检索到的.该名称用于确定加载哪个配置文件以及要使用哪些客户端文件.SVN中设置为空.当复制到 Web 服务器时,它由我们的部署脚本设置.在我们的本地开发机器上,一个环境变量定义了我们想要使用的站点.

Each site gets a unique name (say, "foo" and "bar"), which is retrieved from the Web.config file at run-time. The name is used to determine which config file is loaded and which client-side files to use. The setting is blank in SVN. It is set by our deployment scripts when copied to the web servers. On our local development machines, an environment variable defines the site we want to work with.

站点特定文件的文件结构如下所示:

The file structure of the site-specific files would look like this:

|- Config
|     |- AppSettings.foo.config      <- overrides Web.config AppSettings for "foo" site
|     |- AppSettings.bar.config      <- overrides Web.config AppSettings for "bar" site
|- Content
|     |- CSS
|          |- main.css               <- default CSS file for all sites
|          |- main.foo.css           <- CSS overrides for "foo" site
|     |- Images
|          |- logo.jpg               <- default logo
|          |- logo.foo.jpg           <- logo used if site name is "foo"
|          |- logo.bar.jpg           <- logo used if site name is "bar"

到目前为止,这对我们来说效果很好.向特定站点添加新功能就像将功能添加到我们的代码库中一样简单,并且只为该站点启用它.

This has worked great for us, so far. Adding a new feature to a specific site is as easy as adding the feature to our code-base, and only enabling it for that site.

这篇关于单个代码库多个网站的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆