1

Our company has a client/server product which we want to give the client out to customers to try out, against a test server with dummy data where all users default to a single dummy account.

To summarize the product, in a real world situation the server would be deployed on the customer's hosting environment, and the client app would be given out to the customer's own users. The client app uses SOAP web services to communicate with the server and we use mercurial for version control of both client and server codebases.

My interests as a developer are preserving maintainability of both codebases. I also believe the behavior of the client should be identical whether it receives dummy or live data. I need to be able to push bugfixes from the live back into the demo system. However I need the demo version to have specific behavior (for example, using a dummy account on the server that is populated with dummy data).

In order to try to reconcile these interests have branched the server codebase with hardcoded settings to show only dummy data and to force all logins to use the dummy account. The demo server is deployed to the cloud. We then have a client that is configured in the installer to point to this cloud server instance, and this is available for download to prospective customers to try out.

I am not sure if this is the best approach. Some have suggested I should hardcode the demo functionality into the live server code, and have it configurable with a hidden flag - this would avoid the need for a branched codebase altogether.

The reasoning behind my approach is that adding hard-coded demo behavior in to the live codebase just for a single deployment seems to me like a code smell. The branched server allows us to continue developing the server platform on the "live" branch and pushing bug fixes into the "demo server" branch, and the web service contract and client codebase remain unchanged.

To me this seems like a good separation because the at a high level, I believe the behavior of the client should be identical regardless of whether it is receiving live or dummy data from the server.

My question is whether the wider dev community sees a problem with this approach or has a better strategy. Is my reasoning valid? What is best practice for managing the codebase for a demo system (with a dummy account/data) alongside a live system?

4

3 回答 3

3

There are no valuable advantages there, only extra merging effort. If the difference between demo and live is not critical, I'd suggest maintaining a single codebase.

In order to customize demo behavior I'd suggest the following:

  • conditional code inclusion: #ifdef DEMO ... #endif. You have single codebase, you have "hardcoded" strings, but they wouldn't compile for live version.

  • runtime plugins, when you have somewhat interface IDataProvider and configure demo to use DemoDataProvider. You have single codebase, pluggable demo code, which you can exclude from live distribution.

于 2012-11-18T12:50:37.767 回答
2

I unsderstand your point of view but branching will force you to merge branches to integrate changes in your demo. In my company we have several products using the same code base, a the beginning to save time we forked the codebases, but now we have trouble integrating evolutions and backporting evolutions in branches so instead we use compile time differenciation of the same code or runtime. So my advice (I m not the community :) ) is to not branch

于 2012-11-15T22:50:44.270 回答
0

I'm not sure what technology you are using, but in PHP we have the environment flag (testing, development, production). Using the env flag you can then have different runtime variables set to reflect the behavior of the system. You could tie a sub domain (say demo.yourdomain.com) to the env, set it and define how you want your system to behave (get data from a dummy database, for instance).

http://php.net/manual/en/reserved.variables.environment.php

Hope it helps.

于 2015-07-21T16:44:40.290 回答