当社には、すべてのユーザーがデフォルトで単一のダミーアカウントを使用するダミーデータを使用するテストサーバーに対して、クライアントに試用してもらうためのクライアント/サーバー製品があります。
製品を要約すると、実際の状況では、サーバーは顧客のホスティング環境にデプロイされ、クライアントアプリは顧客自身のユーザーに配布されます。クライアントアプリはSOAPWebサービスを使用してサーバーと通信し、Mercurialを使用してクライアントとサーバーの両方のコードベースのバージョン管理を行います。
開発者としての私の興味は、両方のコードベースの保守性を維持することです。また、クライアントの動作は、ダミーデータを受信する場合でもライブデータを受信する場合でも同じである必要があると思います。ライブからデモシステムにバグ修正をプッシュできるようにする必要があります。ただし、デモバージョンには特定の動作が必要です（たとえば、ダミーデータが入力されているサーバーでダミーアカウントを使用するなど）。
これらの利益を調整するために、サーバーコードベースをハードコードされた設定で分岐して、ダミーデータのみを表示し、すべてのログインでダミーアカウントを使用するように強制しました。デモサーバーはクラウドにデプロイされます。次に、このクラウドサーバーインスタンスを指すようにインストーラーで構成されたクライアントがあります。これは、見込み客が試してみるためにダウンロードできます。
これが最善のアプローチかどうかはわかりません。デモ機能をライブサーバーコードにハードコードし、非表示のフラグで構成できるようにすることを提案する人もいます。これにより、分岐したコードベースが完全に不要になります。
私のアプローチの背後にある理由は、ハードコードされたデモ動作を単一のデプロイメントのためだけにライブコードベースに追加することは、コードの臭いのように思えるということです。ブランチサーバーを使用すると、「ライブ」ブランチでサーバープラットフォームの開発を継続し、バグ修正を「デモサーバー」ブランチにプッシュできます。Webサービスコントラクトとクライアントコードベースは変更されません。
高レベルでは、サーバーからライブデータを受信しているかダミーデータを受信しているかに関係なく、クライアントの動作は同じである必要があるため、これは適切な分離のように思えます。
私の質問は、より広い開発コミュニティがこのアプローチに問題があるのか、それともより良い戦略を持っているのかということです。私の推論は有効ですか？ライブシステムと一緒に（ダミーのアカウント/データを使用して）デモシステムのコードベースを管理するためのベストプラクティスは何ですか？