我们开发了一个使用单一代码库的系统,包括四个带有管理网站的Visual Studio项目和面向客户的网站(每个系统都有自己的MS SQL数据库).
这一直很有效,因为所有新网站(包括管理员)都在SVN中引用相同的代码库项目,因此对代码库所做的任何更改都可供所有网站使用.
每个网站都有不同的母版页和不同的用户控件(.ascx),因此虽然网站背后的主要编码是相同的,但部分不同.
我们现在遇到的问题是,如果存在错误,功能更改或新功能,我们必须在所有站点中单独实施(对于管理员和客户站点).这开始让我们感到疯狂,也意味着我们在实施变更方面存在巨大的误差.
我曾考虑过使用svn:externals,但这会变得很乱.
可以选择从主网站和主管理系统进行分支,但合并以获取新代码是网站不完全相同的主要问题.
我认为一个很好的概述可以说每个站点的标记完全不同(除了管理站点,这只是一个主题更改)但代码库是相同的.
管理这个的最佳方法是什么,还是我们坚持做大量的复制和粘贴？
你想明确哪一点？
出现的问题是在页面JavaScript不同的情况下,HTML布局可以在网站之间完全不同.但页面的代码是相同的.
所以我需要'同步'文件和文件夹,例如在app_code中找到的文件和文件夹,但这里也存在问题.
站点1和站点2可以完全相同,只是一个不同的主题.站点3也有不同的主题,但它也有一些只有这个站点需要的定制代码,app_code中的一些代码也对站点1和站点2的行为有所不同
现在我可以通过分支轻松实现这一点,但是当合并到新分支时,如果存在代码差异,那么将会发生重大冲突.
合并也将成为一项大任务并且需要很长时间,因为我们只需要合并某些文件夹和文件,尽管您无法通过分支合并单个文件(这可能是错误的).
例如:
在root中有一个download.aspx,它返回一个流作为响应而不是一个页面,用于通过系统推送所有下载请求.
因此,站点1和站点2中的此页面是相同的,但在站点3中,它执行了额外的操作,这是其他站点不需要或不需要的.
我们不希望这个定制功能成为一个重载,因为我们不希望/需要它为其他网站,我们现在不能再合并这个文件,从主网站,它必须手动合并.
希望这能更好地解释我想要实现的目标.
基本站点结构
|- App_code
|- App_Themes
|- Bin
|- Content
| |- Flash
| |- Images
| |- Scripts
| |- Uploaded
|
|- Controls
| |- MasterPage
| | |-MasterPageControls
| |
| |- Navigation
| |- Search
| |- Templates
| | |- Control Templates
| | |- Page Templates
| |
| |- WebServices
|
|- Errors
|
控件导航,搜索,模板下的所有内容都是.ascx文件.
在根目录中有几个文件,包括default.aspx,download.aspx和preview.aspx
这些是网站的主页(忽略错误页面),所有页面都是从DB动态创建的.
Controls文件夹是网站之间的大多数更改发生在MasterPage和所有其他用户控件的位置.
几个月前，当我们开始大量重写Web应用程序时，我遇到了这个确切的问题。我们有两个几乎完全相同的站点的单独版本。后端代码是99％相同的，而JavaScript，CSS和其他前端东西却非常不同。我们将这两个站点放在同一SVN存储库中的不同主干中，这很快就成为了在它们之间复制和粘贴通用代码的噩梦。由于文件中的细微变化，修补和合并非常痛苦而无用。
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.
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.