Our company has a client/server product that 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 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 the 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 bug fixes 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 into 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 the best practice for managing the codebase for a demo system (with a dummy account/data) alongside a live system?
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