程序版本控制问题，一套程序跑上百家医院如何做好版本控制

[singworld]

有一套医疗程序，同时给上百家医院使用 假设程序有 1,2,3,4 功能模块

A 医院全部上了 B 医院上了 1,3,4 C 医院上了 1,2,3 但模块 3 有部分修改需求 D 医院第一年上了 1,2 模块对 1 有部分修改需求，次年又上了 3,4 模块又有部分修改需求

想请教一下如何做好版本管理

[fengjianxinghun]

唯有复制 n 份

[unclemcz]

过来人的不成熟经验，医院业务系统（特指 his 这种强业务相关）搞同一版本就是作死，你很难找到两家业务流程完全一样的医院。和设备配套的系统则是越统一越好。

[shootsoft]

我建议你在每一个模块或者 feature 开发的时候加上一个开关，做好开关两个状态的测试，每个客户都有一个自己的配置文件，记录了每一个开关的状态。走正常的开发流程分支管理（）就行。

[shootsoft]

手机有点问题括号里是比如 git-flow

[pagxir]

这个其实不属于版本控制范畴，而是扩展性设计领域。

[reus]

做成可配置的，然后做好测试，确保各种配置下，都能正确运行。
复制 N 份？你有钱你可以试试，招人要钱，出医疗事故要赔钱，你自己掂量。

[Inside]

目前能想到的就是一条主干，拥有所有功能。
然后按功能组合的不同，每个组合 release 一个分支。

功能有修改的时候从某个 release 分支 fork 一个特性分支出来修改，然后 cherry-pick 到需要这个新改动的 release 分支去，如果改动是面向所有医院的，从主干 fork，然后合并到所有 release 分支。

如此，至少做到了每个需求的代码只写了一次。

当然，每个功能都有开关是必须的。

[zartouch]

我们以前有个老系统就是这样的，因为代码写的太烂没人敢随便改，以至于当其中一个下游有改动的时候，就创建一个新的 release 版本，这样就算出事也不会影响到其他下游，到现在要维护 20 来个 release 版本。如果某个改动针对所有版本的话，因为要测试每个版本，每次上线测试 4 周，分批上线又要 2 周的时间，简直是项目管理的灾难。很多业务本来应该在这个系统修改，因为这个，只好在上下游系统做 workaround。 到我们今年接手，构架师 review 以后发现完全无法维护，决定重写。

如果现在你们有人力还是慢慢重构系统，对不同的流做不同的配置，做好自动化测试，保证一个改动不对其他业务流产生影响。复杂的业务系统正确的做法是的好的领域驱动设计，加上完善的测试覆盖。千万别搞多个版本，现在省时间，过几年要命的。

[lights]

代码层面的特性开关，Google 搜索「特性开关」有不少介绍的文章的

[Antidictator]

不能用权限控制吗？

[mywaiting]

挺有意思的一个问题，其实稍微大一些的服务政企的软件公司几乎都会遇到这样问题

这远不只是代码版本的控制问题，我觉得这中间混合了软件工程中所有能遇到的问题

开发、测试工程师就这么多，服务的企业 /商家 虽然类型大体一样（比如医疗行业 /能源行业），但每个企业甚至每个企业的子公司都会有自己乱七八糟的要求，这些要求不只是什么 UI 设计、流程，很多时候甚至要动到底层数据设计的，这时候问题就很多了

我很想听听大神们对于这样的问题的看法

[zhuweiyou]

目前工作中也有类似的情况。
我的做法就是一套代码 + N 套配置文件。

复制多个项目维护会累死。

[anyele]

mark， 我能想到的就是一套代码， 做开关控制

[ericgui]

@shootsoft 这个 idea 非常高明，微软就用这个思路

[TonyLiu2ca]

用 Cloud。如果是旧系统，弄个新的更新模块组 /机，并用 cloud 服务，将各个医院的配置文件集中管理

[tomczhen]

这个不是一个完全的技术问题，需要建立在良好的设计之上才能解决。事实是不论如何做版本管理，最终落地都会对开发人员有水平要求，而人员成本直接决定了版本管理方案最终能不能实行下去。对于很多小公司，由于人员流动高，管理水平有限，一份代码复制 N 份，一个客户一个压缩包是常态。

当初我选择的方法是一个客户一个分支，然后可以合并的功能合并到主干，并做成可配置化，分支需要主干的功能时由对应负责的人去从主干合并到分支。数据库这边不使用所谓的保留字段，会造成同一个个字段不同客户有不同的业务意义，涉及到功能代码升级时无法平滑升级。

实际实践中仍然一堆问题，主要是合并代码时对操作的人要求比较高，分支负责人通常都图方便，选择直接复制粘贴对应代码解决。当主干功能模块出现 bug 修复后，无法找到合并记录，还得人肉再对比修复。后面经过几次人员更新，又变回压缩包解决的方式了。

后面我想明白了，在一定规模下，压缩包这种方式也确实可以有效降低人员要求和管理要求，也算是符合成本的解决方案。

[weiqk]

git 我用的不多，但是我知道 svn 一个 tag 或分支都能解决你这个问题

[Humorce]

二次开发，复制一份单独管理即可。

只需要往主分支上把大量需求的功能加上，
中标之后，二开的费用医院给得起。

[yuzo555]

除非你主版本做得 功能 /开关 都和齐全，否则别想“最新版本一统天下”

[msg7086]

这样相当于为开源软件维护 mod 版，简单的做法是每个 mod 维护一个分支，每次主干升级以后 mod 分支 Rebase 然后做测试。主干破坏性升级后 mod 分支单独修复破坏的部分。