SCMLife.com

 找回密码
 立即注册

QQ登录

只需一步,快速开始

扫一扫,访问微社区

查看: 1604|回复: 1

[讨论] 版本控制选型,能否回归到实际应用中?

[复制链接]
发表于 2017-12-19 18:22:20 | 显示全部楼层 |阅读模式
: s/ F7 |9 \: O* \
背景起因:8 K) y) j& `! u/ V- z  p/ `! w
有位新入坑的朋友,刚接触这个岗位,学习了一些配置管理的理论知识,不知道如何往下深入。1 z8 M) p, b* j! D
变成了因为岗位上的事务需要被动响应而工作(比如权限管理,比如构建管理,比如发布管理,比如审计,比如持续集成等等),慢慢开始迷茫.... J) a% Z( Q3 x$ G. a/ x/ C" \' M
这个工作是否遇到瓶颈了,所掌握所了解就是全貌了?慢慢陷入达克效应中...
1 l0 g1 v& |( a( H! v$ @这个讨论是希望所有从事这个岗位的朋友们,除理论知识外,还能从实际应用着手重新思考配置管理价值体现,这贴就以版本控制的选型开始吧..1 V7 @0 c; m# G; }5 y
: o; U$ s2 z$ R$ h
议题:; Y' R/ C6 p) d3 D- M+ @( }
看到论坛里各类版本控制工具/系统的帖子都挺多,选择原因,可能如下:
2 e0 v4 V! ^/ o" a; j, j6 E  {1、公司一直在沿用这套版本控制工具/系统,由于需要保留源码历史记录,已经绑上贼船" C( v$ q. [. \4 k, `- ~' [+ {! U
2、因为免费,因为不用再折腾没有新的成本投入,使用上也未遇见重大缺陷,就继续使用
9 x; t# }+ x/ X7 r3 r& r) e- Q4 M3、业界都在用这套版本控制工具/系统,网上可查资料多,所以我们也用了, E$ h" N& Y  a& X2 k
4、根据认真评估甄别,确定的版本控制工具/系统
3 }. [9 ?! [8 [  E4 T) @" `5 e! h, F6 d
其中第4点,认真评估甄别,可有实际可操作的分解步骤?大家一起探讨一下?我先来几项
* s/ E# n$ F- q8 j$ k2 ~% n& Z4 j$ d0 F8 I* j  Y  m8 R# J
一、从源码规格分解,看性能
# e& n! N/ T/ G' J/ V; K: g单个项目配置库源码规模(定义假设条件)
2 y, i  e& r+ w5 }& V! z, S巨型:1g以上: `  r1 V( Z1 h5 Y
大型:500mb~999mb
5 J6 I8 n& W& D$ \* U: T中型:300mb~499mb
/ O3 s7 z+ H1 G2 G6 I8 s小型:100mb~299mb! D* `4 I5 H$ Z
微型:10mb~99mb* S: _- e8 q! ?+ t: ?1 n0 i
单个文件大小 50kb~5mb(碎文件多,目录层级深),研发规模500+,并发请求20~302 J) {: ?" p1 E2 ^1 W$ B0 [9 a
那么,单从源码规格来看,哪些规格适合本地化管理,哪些规格适合云端托管?' n% k# j$ S# `8 {
同硬件条件下,本地化管理的版本控制工具哪些性能更优(获取代码、集成代码、提交代码),大家的依据是什么?% j+ s' ^% }, I- h/ I2 p3 P
同费用配置下,云端托管的供应商哪些性能更优(获取代码、集成代码、提交代码),大家的依据又是什么?
5 T( Q% |* s4 a* y
& v) V6 z/ ^) [& r- O6 b. I二、从并行开发频率分解,看易用性% G0 u  ?5 g& P, c: }4 Q: ^
项目二次开发,并行开发频率(定义假设条件)
; ^7 O  |: Q& P/ }! F超高频:同一项目,一天10个以上分支并行开发,每天都有分支需要集成和发版
' H1 ~& f) V- c- G7 g; Y高频:同一项目,一天5~9个以上分支并行开发,每天都有分支需要集成和发版
5 O, a& q: n% L中频:同一项目,一天1~4个以上分支并行开发,每天都有分支需要集成和发版
1 h8 K% p( b1 ~  B低频:同一项目,不一定每天都并行开发和发版,可能很长周期内都是串行开发) y6 z  J! M! E5 ?  Z0 i7 Y) B
那么,单从项目并行开发频率来看,哪款版本控制工具/系统更贴合各种频率的使用,集成和冲突解决更直观便捷易用,大家的依据又是什么?
0 J, I  N+ n$ X! ]7 w8 P
) N6 O! L2 @6 W- g三、从并行开发协同场景分解,看贴合度
2 d, O! `& C2 E& g# ]项目二开,协同方式(定义假设条件)
# P8 i% j0 L/ i2 b) U本地化协同开发:研发集中在一个固定场所,协同开发,涉及代码集成) H2 c3 l' r" V2 V
本地化独立开发:研发集中在一个固定场所,独立开发,独立交付8 Q. c6 }- A- N8 h6 L
异地化协同开发:研发分散在全国各地,协同开发,涉及代码集成
$ M* w* }% v# {0 D$ ~( P异地化独立开发:研发分散在全国各地,独立开发,独立交付5 @& h8 C0 R" o" E; V4 q- K4 p9 @. x3 u
琳散的驻场开发:研发集中在一个固定场所,协同开发,偶尔需要到客户现场出差驻场开发
. a! r7 h& f) w; N' p1 _; Z- f那么,单从协同方式看,哪些方式适用于集中式版本控制工具/系统,哪些适用于分布式版本控制工具/系统,哪款贴合度更高,大家的依据是什么?
4 {; q6 T1 q& m! \0 b+ x8 t6 A5 ]5 _5 S7 B6 t
如果我们将场景组合更复杂一些(从一、二、三中组合下条件),我们应该怎样合理评估甄别最适用的版本控制工具/系统?
1 ?9 [- X7 a8 A6 }, _( F+ Y4 X0 O; M3 e# Z' W3 ~2 v4 b
以上分解出的几个维度,仅仅针对配置管理实际应用中的源码版本控制选型...个人思考比较有限,也请大拿参与探讨不吝赐教
  H/ i% ?0 }/ L1 K4 S5 e5 c% |1 b7 @6 F
肯定还有很多前辈们有更多的建议或见解,希望能一起梳理出来,为以后初步接触的朋友铺铺路... 拜谢...! E, M8 f0 {7 R: r) j
# ?" r- p, V3 \6 a0 f9 O
发表于 2017-12-27 11:16:41 | 显示全部楼层
不错哦。
回复 支持 反对

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关闭

SCMLife推荐上一条 /4 下一条

QQ|小黑屋|手机版|无图版|SCMLife.com ( 京ICP备06056490号-1 )

GMT+8, 2018-10-22 01:49 , Processed in 0.058060 second(s), 6 queries , Gzip On, MemCache On.

Powered by SCMLife X3.4 Licensed

© 2001-2017 JoyShare.

快速回复 返回顶部 返回列表