商城産品如何應對多個客戶不同的需求修改并釋出對應客戶的檔案

生産環境上有很多個版本的商城産品，可能存在以下幾種情況：

1、由于授權和商務等一系列的原因，可能有些有1.0、2.0、3.0...這樣的版本，而這每個版本都定制了很多功能，加入一些特定使用者要求的特定需求，但是唯一相同的是主體的下單流程。

2、上面這些版本的系統都是出自同一個主體相同的綜合商城，每次綜合商城的功能是最全且bug最積極的修複。

3、主體的産品商城修複的某些bug，比如下單流程的小bug修複了，那麼依托于主體産品定制開發的每個小商城都必須全部手動更新。

4、也有可能，下面的某個小商城在定制開發的途中發現了某個bug，而主體産品商城沒有更新，需要一起同步更新到主體産品商城。

5、當主體的商城産品要從v1更新到v2時，下面某個小商城也要一起更新時，小商城有定制的部分但是要更新到v2。

有以下幾種方案：

1、每個定制開發的小商城全部獨立一套代碼進行開發部署

2、主體更新功能或修改bug時或者下面的更新了某個bug要同步到主體時：

①使用Beyond Compare 檔案比對工具比對，但是需要消耗大量的人力和位置的檔案；

②使用svn的分支功能進行同步，目前是最優的辦法，結構清晰，有版本進行對比，且能批量版本進行同步【推薦】

3、在每個小商城上的代碼更目錄都标注是從那個主體商城遷移開發的，包括更新了之後，都要簡要标明，有助于以後的代碼更新和svn分支合并。

和discuz這種大型産品的差別：

1、其實discuz這種大型産品是一整套一成不變的功能，無論是A客戶還是B客戶，用的功能已經定死，隻能官方說升才能升，其餘的一律不修改。是以可以打包成安裝檔案進行安裝，而無需使用每個客戶一套代碼進行開發。

2、商城的定制開發對于我們來說是必須的，A客戶可能需要短信驗證加特殊說明等，B客戶喜歡從頭改到腳，如果打包成安裝檔案那麼意味着人工去修改特定的頁面屏蔽某些功能，每次修改玩主體産品商城時，都要根據每個客戶不同的授權進行功能的屏蔽。如果是幾個客戶還可以這樣做，但是10幾個的時候，到20幾個時候那麼就很痛苦了！

3、是以，最後總結出定制需求修改的産品，全部一套代碼進行開發，采用svn的分支進行功能合并和代碼bug的修複（雙向）。