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

If I understand the issue correctly, you have the code for four broadly similar websites in one repository. A website instance has custom features. The punchline in the original posting, the question, expresses concern about being "stuck doing a lot of copy and paste." At various points you indicate frustration with "merging" and "manual merging."

I take it you are using svn to distribute new code to the four hosts.

Perhaps your codebase is approaching a point where the common material could be profitably considered to be a library. In this view, each of the four websites is considered to be an application built from the library. If so, then it may make sense to give each of the four apps its own repo in subversion. The developmental effort will be to separate the common features from the custom features, perhaps making the API on the "library" code a little more crisply defined. Each host then checks out the library code and its own app.

Is this close to what you're thinking?

Answer 2

Three thoughts, in ascending order of utility and effort:

1) Honing in on the "the markup is totally different per site (except the admin site, which is just a theme change) but the code bases are the same."

How much "code" can you move to a DLL project that gets shared? If it's almost all of it, then you can maintain separate projects for each of the sets of markup and those will use the DLLs as reference.

Obviously if you've got a lot of code that's not in AppCode, this isn't going to be feasible at all. If not, it may be a quick route to less insanity.

2) Would it be possible to maintain a repository for the shared code with separate repositories for each of the Sites? Then you'll need to create your own deployment script to handle pulling the source code from correct repositories and putting it in the right places.

Depending on how tightly coupled the code / markup is, this may not be feasible either.

3) Finally, what about moving the differing code into a database and having the app generate itself on deployment?

Obviously that's the most involved, but it gets you where you want to be.