Deployment/Management of Web Sites for Multiple Clients

Question

I have a small business that sells website solutions to clients. The websites serve the same purpose; to allow the customer to send and schedule SMS messages.

Each website is slightly different. For example, 1 site has mandatory information such as address details and group name while the other has different requirements such as logging the IP address of a user but does not need any address details.

All the websites are built using LINQ TO SQL and are just websites, rather than web applications.

Each website has its own database on my server.

Each website uses an exe to send out the messages. That exe is the same exe but each website has its own copy and scheduling procedure located within the bin directory of the site and is fired using Windows scheduled tasks.

Each website uses the same web service to communicate with a central server that sends messages and returns a response.

The customers can change the ASPX pages but not the code behind.

At the moment, I have a file structure on my dev machine that reads something like:

Client1Dev Client1_Published

Client2Dev Client2_Published

... And so on

Separately, there is the polling application (a windows console app)

When I make a change, I publish the client site to its _Published directory and then copy the DLL from within the bin directory to the production server.

My question really is what would you do to manage this stuff? If Client 1 want's a change, I make the change to the dev site, copy to published and then FTP to production.

When building new sites, its a nightmare because there might be changes all over the place in different client projects which could be useful for a new customer.

If I find a bug, its a real nightmare as I then need to update all of the sites 1 by 1 ensuring the bug fix does not break a particular project.

Any advice on this?

Answer 1

Source control, automated tests. In short, process.

You'll want to have a main line of development, and perhaps one branch per client. Some changes made to a client branch want to get merged into the main branch, then out to the branches for the other clients.

You'll want to test these changes by running automated tests, and these tests may also need to be versioned for different clients.

In fact, you may need to ask yourself if it's worth the effort to allow clients to make so many changes. You may need to limit the number and kinds of changes they can make, just to retain your sanity.

Answer 2

I have worked with a similar setup and it is a nightmare, with no easy way out.

One option would be to use svn and have a branch for each client, you can then track where changes were made and copy them to and from a central trunk. This is not one of the "standard branching patterns", but I have seen it used in with a huge code base with many clients and it works ok. It depends on how much your clients pay for maintenance.

Personally I think that you would be better off providing a [flexible CMS][1] and giving each client a separate database and theme. It would be a load of work to get there so you may want to roll it out slowly but would be much easier in the long run. Having worked on in house and open source CMS' the open source route seems to have many benefits.

You can have specific modules for each clients custom functionality, keeping the client code nicely separated from the core code. Also by doing this you solve the code maintenance issue as the cms code is separate from the customer specific code.

I think that the other posters have a point when talking about automated testing and build management, but that is at the end of a long road, for small scale websites I don't know if you could justify the effort.

Answer 3

Take a look at Eric Sink's did the source control guide and then have look at something like Cruise Control.net to improve your build process. Most auto build tools can be customised with scripts etc to do whatever bespoke steps you need prior to pushing the code out.

Answer 4

Tough one, but one way to minimize the complexity could be to have only one branch in your source code repository and then try to miximize the Open Closed principle as stated in SOLID. That way it should be posible to provide the changes requested by your customers without branching your source tree. The first idea that sprung to my mind was "use a factory pattern" but I have learned the hard way not to throw patterns after any problem that I see, but still..