Single Codebase multiple websites

Question

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

Answer 1

I am not sure I understand your situation correctly, but you can find clues on how to maintain the SVN repository in the Subversion book, under chapter 4.

It seems you either have to establish good routines for the SVN tree, or you have to change the code so that as much as possible is common to all the web sites, with the differences being configurable. For instance, you might be able to create a main project with site-agnostic code, and then code the changes as projects that build on top of it.

As for updating the sites themselves, this must either be done by synchronizing with the appropriate points in the subversion tree, or you have to perform a new release (or upgrade).

Answer 2

I'm going to start with thanking everyone for thier input.

I have now solved (more or less) the issue.

What I have done is move all images into the Themes folders and also created subfolders in the templates and controls folders where bespoke controls will live. I had already created some features in the database schema that gave me a helping hand along with this.

My preplanning of the system had a lot in it that I hadnt fully implemented and had forgotten about.

I have also seperated out some of the code as well for the likes of the webservices, well atleast for the webservices that can survive on their own anyway.

Collectively we got to the solution so Im not sure who to award the points to?

Answer 3

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.

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.

Answer 4

Like others, I'm a bit confused as to your problem, but I do think I have a general understanding of the issue. What you need to try to do in this case is abstract the customizations into separate libraries per client / project and leave the original codebase uncustomized. The base code should contain only the generic functionality applicable to all sites (although some functionality could be altered so that you could toggle its availability depending on the need).

If you do things right, you should be able to export / publish the original code base to any given site at any time and not screw things up. Any customizations should remain intact.

Answer 5

Establish a continuous integration server. Practice active code generation.

See 10 tips to integrate CodeSmith into your processes.

Answer 6

You say you have one SVN repo with the code base for all the sites. So unless I'm misunderstanding, can't you simply move any shared components into that repository?

Things such as the in-page Javascript you mention should be made external where possible. If the HTML layouts are completely different, chances are the Javascript may be significantly different.

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 dont want this bespoke feature to be an overload as we dont want/need it for the other websites

Can't you extend the download code on site 3, so you have a common base across all sites, but extend it on site 3.