SCMLife.com

 找回密码
 立即注册

QQ登录

只需一步,快速开始

扫一扫,访问微社区

查看: 2080|回复: 1

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

[复制链接]
发表于 2017-12-19 18:22:20 | 显示全部楼层 |阅读模式

3 L4 P. \9 L# J背景起因:
) r9 X) M  ]$ E有位新入坑的朋友,刚接触这个岗位,学习了一些配置管理的理论知识,不知道如何往下深入。
; Y+ _5 O/ Q, Z8 E0 A5 }* A变成了因为岗位上的事务需要被动响应而工作(比如权限管理,比如构建管理,比如发布管理,比如审计,比如持续集成等等),慢慢开始迷茫...
3 e4 {" e4 a  P$ J  Z7 s这个工作是否遇到瓶颈了,所掌握所了解就是全貌了?慢慢陷入达克效应中...
7 V1 o5 w9 z9 B* j这个讨论是希望所有从事这个岗位的朋友们,除理论知识外,还能从实际应用着手重新思考配置管理价值体现,这贴就以版本控制的选型开始吧.." E; j$ D% L0 T* t" S4 i. @- \# S
, ]$ m2 Z, J* y; p9 B& [# W. t
议题:: ]2 h" l) x+ L; m% ]* c' H
看到论坛里各类版本控制工具/系统的帖子都挺多,选择原因,可能如下:/ L7 o5 p' |3 R2 s* m
1、公司一直在沿用这套版本控制工具/系统,由于需要保留源码历史记录,已经绑上贼船  P. W2 f# w# W+ a
2、因为免费,因为不用再折腾没有新的成本投入,使用上也未遇见重大缺陷,就继续使用" l; C8 {- ^/ c, u& C
3、业界都在用这套版本控制工具/系统,网上可查资料多,所以我们也用了; L, b/ `2 K" G. R
4、根据认真评估甄别,确定的版本控制工具/系统: o' u& Z8 D, n: b" [, }

5 W4 L& k7 Y' x# Q, Q$ N) v其中第4点,认真评估甄别,可有实际可操作的分解步骤?大家一起探讨一下?我先来几项# ?+ k( }) k) l. g) r, O
; L0 ~+ o/ Y  D. g" M: S: G8 [7 e
一、从源码规格分解,看性能
  Y4 o, ^* S0 Q& C8 W0 O单个项目配置库源码规模(定义假设条件)
0 e0 s' v% F  e4 @& [2 W巨型:1g以上. x: h2 T3 |2 Y7 {' V" }
大型:500mb~999mb6 G+ a2 B0 i, O; \
中型:300mb~499mb6 v& e$ m# H( e* }; @
小型:100mb~299mb- e  B) N! ]$ M, r: a: }
微型:10mb~99mb
* @( [: M' Y) ]/ C单个文件大小 50kb~5mb(碎文件多,目录层级深),研发规模500+,并发请求20~30! u* ]: m+ o, B+ [% d& _0 H
那么,单从源码规格来看,哪些规格适合本地化管理,哪些规格适合云端托管?; K$ H. k5 d# C+ e5 {* u
同硬件条件下,本地化管理的版本控制工具哪些性能更优(获取代码、集成代码、提交代码),大家的依据是什么?
+ ]+ K. d* s) M! E! p同费用配置下,云端托管的供应商哪些性能更优(获取代码、集成代码、提交代码),大家的依据又是什么?
' l, o' c: Z: z- }2 q/ F( _7 z1 G6 K! [1 S
二、从并行开发频率分解,看易用性
4 ?$ J; \9 \" X项目二次开发,并行开发频率(定义假设条件); |; T9 c. c7 X% |- W- ~
超高频:同一项目,一天10个以上分支并行开发,每天都有分支需要集成和发版  N5 q9 V  B6 S% N/ [5 G; g" F
高频:同一项目,一天5~9个以上分支并行开发,每天都有分支需要集成和发版/ K, @; q' [" m- U- w( B3 C9 y
中频:同一项目,一天1~4个以上分支并行开发,每天都有分支需要集成和发版
/ b5 [' Q/ H# z2 W  p4 H" c低频:同一项目,不一定每天都并行开发和发版,可能很长周期内都是串行开发
$ v  Z( ^3 a7 m: k那么,单从项目并行开发频率来看,哪款版本控制工具/系统更贴合各种频率的使用,集成和冲突解决更直观便捷易用,大家的依据又是什么?
+ i% w) a1 p1 }- O" M5 l1 a  f1 D# j
7 y4 c' n+ j2 u) M0 r* W: u三、从并行开发协同场景分解,看贴合度4 v/ J: L, x8 e7 K% {8 V
项目二开,协同方式(定义假设条件)
3 V; m( O- w* a3 b& D本地化协同开发:研发集中在一个固定场所,协同开发,涉及代码集成
. Q  x, r- `1 `7 {! B  p+ }' ?本地化独立开发:研发集中在一个固定场所,独立开发,独立交付7 T! a; @' o# T5 v2 @9 w
异地化协同开发:研发分散在全国各地,协同开发,涉及代码集成. I! Q9 F; C+ p$ U- {2 h& v
异地化独立开发:研发分散在全国各地,独立开发,独立交付
, w1 r- L) K; l& W6 _- O" j2 J琳散的驻场开发:研发集中在一个固定场所,协同开发,偶尔需要到客户现场出差驻场开发
; @5 L" H% h. L# ?2 ?( Y那么,单从协同方式看,哪些方式适用于集中式版本控制工具/系统,哪些适用于分布式版本控制工具/系统,哪款贴合度更高,大家的依据是什么?7 x# A9 V1 z. V5 K

4 b: W' _3 P5 m% [" j* a2 ]- {如果我们将场景组合更复杂一些(从一、二、三中组合下条件),我们应该怎样合理评估甄别最适用的版本控制工具/系统?
7 m# K' _* j  h' Z( q2 e8 p/ Q9 g" Z/ I
以上分解出的几个维度,仅仅针对配置管理实际应用中的源码版本控制选型...个人思考比较有限,也请大拿参与探讨不吝赐教
0 w3 v2 W6 s) t* A7 z0 [4 A! ?+ P6 r
肯定还有很多前辈们有更多的建议或见解,希望能一起梳理出来,为以后初步接触的朋友铺铺路... 拜谢...
/ J0 D0 B9 m" p+ G# o; h
9 P8 m# r( X4 L7 @' G) ?+ ^
发表于 2017-12-27 11:16:41 | 显示全部楼层
不错哦。
回复 支持 反对

使用道具 举报

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

本版积分规则

关闭

SCMLife推荐上一条 /4 下一条

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

GMT+8, 2019-2-20 22:33 , Processed in 0.055832 second(s), 6 queries , Gzip On, MemCache On.

Powered by SCMLife X3.4 Licensed

© 2001-2017 JoyShare.

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