这是一个创建于 1957 天前的主题，其中的信息可能已经有所发展或是发生改变。
有一套医疗程序，同时给上百家医院使用 假设程序有 1,2,3,4 功能模块
A 医院全部上了 B 医院上了 1,3,4 C 医院上了 1,2,3 但模块 3 有部分修改需求 D 医院第一年上了 1,2 模块对 1 有部分修改需求，次年又上了 3,4 模块又有部分修改需求
想请教一下如何做好版本管理
 |
1
fengjianxinghun 2019-07-21 21:36:04 +08:00 via iPhone
唯有复制 n 份
|
 |
2
unclemcz 2019-07-21 22:01:41 +08:00 via Android
过来人的不成熟经验，医院业务系统（特指 his 这种强业务相关）搞同一版本就是作死，你很难找到两家业务流程完全一样的医院。和设备配套的系统则是越统一越好。
|
 |
3
shootsoft 2019-07-21 22:37:01 +08:00 via iPhone
我建议你在每一个模块或者 feature 开发的时候加上一个开关，做好开关两个状态的测试，每个客户都有一个自己的配置文件，记录了每一个开关的状态。走正常的开发流程分支管理（）就行。
|
|
4
shootsoft 2019-07-21 22:38:28 +08:00 via iPhone
手机有点问题括号里是比如 git-flow
|
 |
5
pagxir 2019-07-21 22:41:38 +08:00 via Android
这个其实不属于版本控制范畴，而是扩展性设计领域。
|
 |
6
reus 2019-07-21 22:59:36 +08:00  1
做成可配置的，然后做好测试，确保各种配置下，都能正确运行。
复制 N 份？你有钱你可以试试，招人要钱，出医疗事故要赔钱，你自己掂量。 |
 |
7
Inside 2019-07-21 23:06:08 +08:00 1
目前能想到的就是一条主干，拥有所有功能。
然后按功能组合的不同，每个组合 release 一个分支。 功能有修改的时候从某个 release 分支 fork 一个特性分支出来修改，然后 cherry-pick 到需要这个新改动的 release 分支去，如果改动是面向所有医院的，从主干 fork，然后合并到所有 release 分支。 如此，至少做到了每个需求的代码只写了一次。 当然，每个功能都有开关是必须的。 |
 |
8
zartouch 2019-07-22 00:00:03 +08:00 3
我们以前有个老系统就是这样的，因为代码写的太烂没人敢随便改，以至于当其中一个下游有改动的时候，就创建一个新的 release 版本，这样就算出事也不会影响到其他下游，到现在要维护 20 来个 release 版本。如果某个改动针对所有版本的话，因为要测试每个版本，每次上线测试 4 周，分批上线又要 2 周的时间，简直是项目管理的灾难。很多业务本来应该在这个系统修改，因为这个，只好在上下游系统做 workaround。 到我们今年接手，构架师 review 以后发现完全无法维护，决定重写。
如果现在你们有人力还是慢慢重构系统，对不同的流做不同的配置，做好自动化测试，保证一个改动不对其他业务流产生影响。复杂的业务系统正确的做法是的好的领域驱动设计，加上完善的测试覆盖。千万别搞多个版本，现在省时间，过几年要命的。 |
 |
9
lights 2019-07-22 00:07:09 +08:00
代码层面的特性开关，Google 搜索「特性开关」有不少介绍的文章的
|
 |
10
Antidictator 2019-07-22 00:20:21 +08:00
不能用权限控制吗？
|
 |
11
mywaiting 2019-07-22 00:32:20 +08:00 2
挺有意思的一个问题，其实稍微大一些的服务政企的软件公司几乎都会遇到这样问题
这远不只是代码版本的控制问题，我觉得这中间混合了软件工程中所有能遇到的问题 开发、测试工程师就这么多，服务的企业 /商家 虽然类型大体一样（比如医疗行业 /能源行业），但每个企业甚至每个企业的子公司都会有自己乱七八糟的要求，这些要求不只是什么 UI 设计、流程，很多时候甚至要动到底层数据设计的，这时候问题就很多了 我很想听听大神们对于这样的问题的看法 |
 |
12
zhuweiyou 2019-07-22 00:51:01 +08:00
目前工作中也有类似的情况。
我的做法就是一套代码 + N 套配置文件。 复制多个项目维护会累死。 |
 |
13
anyele 2019-07-22 01:05:01 +08:00
mark， 我能想到的就是一套代码， 做开关控制
|
 |
15
TonyLiu2ca 2019-07-22 01:17:37 +08:00
用 Cloud。如果是旧系统，弄个新的更新模块组 /机，并用 cloud 服务，将各个医院的配置文件集中管理
|
 |
16
tomczhen 2019-07-22 01:30:43 +08:00
这个不是一个完全的技术问题，需要建立在良好的设计之上才能解决。事实是不论如何做版本管理，最终落地都会对开发人员有水平要求，而人员成本直接决定了版本管理方案最终能不能实行下去。对于很多小公司，由于人员流动高，管理水平有限，一份代码复制 N 份，一个客户一个压缩包是常态。
当初我选择的方法是一个客户一个分支，然后可以合并的功能合并到主干，并做成可配置化，分支需要主干的功能时由对应负责的人去从主干合并到分支。数据库这边不使用所谓的保留字段，会造成同一个个字段不同客户有不同的业务意义，涉及到功能代码升级时无法平滑升级。 实际实践中仍然一堆问题，主要是合并代码时对操作的人要求比较高，分支负责人通常都图方便，选择直接复制粘贴对应代码解决。当主干功能模块出现 bug 修复后，无法找到合并记录，还得人肉再对比修复。后面经过几次人员更新，又变回压缩包解决的方式了。 后面我想明白了，在一定规模下，压缩包这种方式也确实可以有效降低人员要求和管理要求，也算是符合成本的解决方案。 |
 |
17
weiqk 2019-07-22 02:53:18 +08:00
git 我用的不多，但是我知道 svn 一个 tag 或分支都能解决你这个问题
|
 |
18
Humorce 2019-07-22 04:09:33 +08:00
二次开发，复制一份单独管理即可。
只需要往主分支上把大量需求的功能加上， 中标之后，二开的费用医院给得起。 |
 |
19
yuzo555 2019-07-22 04:12:13 +08:00
除非你主版本做得 功能 /开关 都和齐全，否则别想“最新版本一统天下”
|
 |
20
msg7086 2019-07-22 04:29:24 +08:00
这样相当于为开源软件维护 mod 版，简单的做法是每个 mod 维护一个分支，每次主干升级以后 mod 分支 Rebase 然后做测试。主干破坏性升级后 mod 分支单独修复破坏的部分。
|
 |
21
saulshao 2019-07-22 04:30:33 +08:00
假设最极端的情况：你的功能有 100 个，但是每个功能都可能用到 100 个医院的不同特性，这个时候实际上就是 10000 个功能。
这种规模的系统肯定是没法管理代码的。 于是折中的方法就是提取出有共性的 80 个功能，这些功能针对 100 个医院使用同样的代码。而剩下的还是有 2000 个.... 但是功能的总数量下降到 2080 个，这是一个极大的进步了。 再继续用上面的方法。使得功能下降到可以接受进行版本管理的程度，然后加入开关。但是如果你这套系统最终有 200 个开关，实际上也是一场噩梦。 其实这套办法完全取决于你的系统有多少个功能.......我感觉开源软件其实就是这么干的。开源项目最大的优点是有几乎无限的开发资源...所以最后什么功能需要接受就成了一个最重要的事情。 我也是搞类似的系统的，目前确实没啥好办法。 |
 |
22
0bject 2019-07-22 05:29:47 +08:00
跟我 2 年前做过的项目一样。。。我是用的 #7 楼的做法
|
 |
23
jorneyr 2019-07-22 07:10:28 +08:00
这个问题非常常见，很头疼，推荐代码用同一套，功能通过配置来启用和关闭，但是当遇到冲突的时候就需要多考虑下。
|
 |
24
flyz 2019-07-22 07:25:26 +08:00 via Android
his 实施，只能说做开关就方便。
医院的个性化流程是因为软件话语权不够强大导致的。 100 个医院 100 个需求，但是梳理标准化流程， 用标准化流程来作为主线，这部分尽量不改。 弥补的确符合逻辑的功能做成开关。 没一个开关要写清楚，这个开是干什么的关是干什么的即可。 |
 |
25
zjsxwc 2019-07-22 07:54:31 +08:00 via Android
每个功能都是插件，
每个插件自己维护一个版本控制， 每个客户提供一个插件配置文件 |
 |
26
wangxiaoaer 2019-07-22 08:04:00 +08:00 via Android
跟我说类似，但不是医院。
我们是一套代码多套配置文件，优点是维护方便点，缺点是代码量庞大，构建耗时，安装包大，启动耗时，因为它相当多个项目的并集。 |
 |
27
est 2019-07-22 08:54:26 +08:00
用班本控制来切换医院？灾难的设计啊。
|
 |
28
razertory 2019-07-22 10:55:23 +08:00
直接上 github-flow 啊。一个医院 fork 一个 repository
|
 |
29
YoRolling 2019-07-22 11:52:15 +08:00
子模块单独全部独立出来，然后 N 个医院 N 个仓库，git subModule 集成？
|
 |
30
annielong 2019-07-22 12:07:09 +08:00
模块化，不过最怕某个模块的功能，必须修改核心代码，这时候核心代码可以加开关，但是如果这种模块多了也是灾难
|
 |
31
momocraft 2019-07-22 12:12:27 +08:00
插件化（框架化）
写测试 可能有帮助 |
|
32
reus 2019-07-22 12:29:56 +08:00
要 fork 也是 fork 模块，不要 fork 分支。fork 模块就是将模块代码复制一份，放到同一个分支里。
fork 模块，有重复代码也没关系，遇到需要修复的，也是修改同一个分支上的不同的文件，而不是多个分支。 后面时间充裕了，可以慢慢合并重复的模块。这个需要一开始就有完善的测试，不然没法保证重构之后还能正常运作。 当然，考虑到很多公司甚至测试都不写的，那可能就会选择 fork 分支，那就后果自负了。 |
 |
33
codehz 2019-07-22 12:35:25 +08:00
之前微软不是有员工说 office 里有一大堆特性开关（ Gate ），每次修改（加功能，修 bug ）都要有开关可以控制。。。然后当然就是随之而来的一堆测试。。。
|
 |
34
qiyuey 2019-07-22 12:37:59 +08:00 via Android
提供标准的能力和扩展点
|
 |
35
GODZZZZZ 2019-07-22 13:42:23 +08:00
感觉不是版本控制的问题，而是功能开关的问题
还有就是可以保证每个医院的某个功能是相同的，而没有各自定制话的东西？ |
 |
36
jinhan13789991 2019-07-22 18:07:54 +08:00
上面都说的很好，模块化。但是祖传代码怎么模块化呢？ 工期在那里排着，只好 fork 分支然后改了。
后面多个分支需求不同，代码差异化越来越严重。感觉就像一辆失去控制的火车，只能眼睁睁看它走向深渊 |
 |
37
janus77 2019-07-22 21:10:36 +08:00
你们公司没那么大能力同时维护多个 oem 的多历史版本，那就开成多项目吧。
|
 |
38
xxxy 2019-07-22 21:54:37 +08:00
最近也遇到了类似的问题。目前是靠开多个 feature 分支启动多个服务来解决，等测试完成后再分支合并回主分支。至于楼主你的不存在最终统一的版本。要不就用七楼的方法，要不就每个医院建一个仓库，把基本功能分出来一个基本仓库，新增的差异部分写在各自的仓库。
|
 |
39
laozhoubuluo 2019-07-22 23:18:44 +08:00
上百家医院，完了还是您这种情况......
这种问题十家八家的，模块化+模块控制可以解决。 Base 框架所有医院共享一个，完了开发标准的 1-4 模块，互不冲突的功能都在标准模块实现，差别从配置文件解决。 完了分支出来 3-C，1-D，3-D，4-D 解决模块间冲突。 如果这个架构扩展成几十家医院，可以考虑按划分二级分支，差别从配置文件解决。 比如北京市同一个医院对接医保系统的各个接口（医保卡认证、报销、查询其他医院用药记录）基本相同。 比如北京统一挂号平台（网上预约号）在北京所有医院适用。 比如北京京医通系统（挂号、缴费、检验单查询）在北京有接近二十家医院了。 问题是如果是共性不多的上百家医院，如果又不能引导需求的话。 我怕最后会出来几十个模块分支，继续 nightmare...... |
|
40
laozhoubuluo 2019-07-22 23:24:08 +08:00
刚才有个小错误：
比如北京市所有的医院对接北京市医保系统的各个接口（医保卡认证、报销、查询其他医院用药记录）基本相同。 另外如果再不行，我觉得需要考虑微软 office 组的某些牛人了。牛到系统里做个大改动，一次改上千个文件完了系统还能 PASS 测试那种。 |
 |
41
chinvo 2019-07-23 05:48:01 +08:00 via iPhone
模块标准化，差异 mod 化，release patch 化
|
 |
42
yansideyu 2019-07-23 10:39:14 +08:00
我们用的配置文件和砍需求，且国家有相关管理规范，砍需求的时候拿着鸡毛当令箭
|
 |
43
brust 2019-07-25 13:45:39 +08:00
一个医院一个分支
|
 |
44
singworld OP 抱歉，没来得及及时回复，感谢楼上各位的建议
目前我们的做法是 如果差异化比较小的部分就做代码层面的控制 差异化比较大的医院就单独开一个新项目 但维护的项目比较多，修改需求也比较多。已经在奔溃的边缘疯狂试探了 |
|
45
singworld OP 好在代码比较老旧的代码，准备重构了。
|
|
46
singworld OP 最悲剧的是手里还有多套老程序还在开发新程序，应用在多家医院，都面临这个情况
|
 |
47
charlie21 2019-08-31 01:16:16 +08:00
https://superphp.org/2019/516.html 谈到的 微软 开关 医院问题
|
Select Language