SCMLife.com

 找回密码
 立即注册

QQ登录

只需一步,快速开始

扫一扫,访问微社区

查看: 1007|回复: 1

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

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

# a3 R  A* T2 A( O: T  d背景起因:/ P! D( ]8 X( P5 h5 n* t. e
有位新入坑的朋友,刚接触这个岗位,学习了一些配置管理的理论知识,不知道如何往下深入。0 @# b5 R# p+ O) z5 k5 F. y& _$ e) Z
变成了因为岗位上的事务需要被动响应而工作(比如权限管理,比如构建管理,比如发布管理,比如审计,比如持续集成等等),慢慢开始迷茫...4 S0 X1 {7 ~6 `6 [
这个工作是否遇到瓶颈了,所掌握所了解就是全貌了?慢慢陷入达克效应中...
0 p; S; g3 N! ?  l/ _$ h9 z3 ^这个讨论是希望所有从事这个岗位的朋友们,除理论知识外,还能从实际应用着手重新思考配置管理价值体现,这贴就以版本控制的选型开始吧..
7 U9 f1 V! Z! F9 N% ~. T: X' V  \& z: D
议题:
7 X4 h: A* ~7 s6 r看到论坛里各类版本控制工具/系统的帖子都挺多,选择原因,可能如下:  @' ^; O8 D4 }+ @5 I
1、公司一直在沿用这套版本控制工具/系统,由于需要保留源码历史记录,已经绑上贼船5 B  |- L2 t5 y3 s: N' p  `
2、因为免费,因为不用再折腾没有新的成本投入,使用上也未遇见重大缺陷,就继续使用3 x& J1 ?0 w7 _+ O1 c, \
3、业界都在用这套版本控制工具/系统,网上可查资料多,所以我们也用了$ o+ _; J- ~7 F6 k6 e9 o
4、根据认真评估甄别,确定的版本控制工具/系统
4 J. {4 Y! V. S; F6 }! V) L% k
其中第4点,认真评估甄别,可有实际可操作的分解步骤?大家一起探讨一下?我先来几项8 q  J& ^, ]2 C& Y) ?

  ~4 ?3 }9 G9 Y4 n: ]5 A; H一、从源码规格分解,看性能
  q0 I) K7 q; v$ N& x. S' p  H单个项目配置库源码规模(定义假设条件)
% R* L  Q. T, x, ~1 ]% ^" x7 q巨型:1g以上
" w5 {1 t% X; }/ _大型:500mb~999mb5 A7 H( g' d' C$ J& |! h6 W. V' n* k
中型:300mb~499mb
+ [; v- G0 k: a" B& G小型:100mb~299mb
" c, B% M. r- D微型:10mb~99mb
- \' P# o! v/ A! e0 D2 R+ A  ^单个文件大小 50kb~5mb(碎文件多,目录层级深),研发规模500+,并发请求20~30
+ J3 w" S7 u, Q4 Z8 H$ {' C3 v那么,单从源码规格来看,哪些规格适合本地化管理,哪些规格适合云端托管?
  l: ?5 A' C" p) W同硬件条件下,本地化管理的版本控制工具哪些性能更优(获取代码、集成代码、提交代码),大家的依据是什么?2 |( s0 }4 U1 H3 x
同费用配置下,云端托管的供应商哪些性能更优(获取代码、集成代码、提交代码),大家的依据又是什么?
- k1 |! j6 ^1 N* K1 _1 j- [( s2 ?
二、从并行开发频率分解,看易用性
  |9 s, ?# c4 C- k7 S& \1 c项目二次开发,并行开发频率(定义假设条件); S1 b) s: M/ @: W) J2 o
超高频:同一项目,一天10个以上分支并行开发,每天都有分支需要集成和发版
( I1 z+ {/ r/ }$ s3 {" C9 V' @高频:同一项目,一天5~9个以上分支并行开发,每天都有分支需要集成和发版
7 F- N1 k* Y- d% w$ j- z2 {中频:同一项目,一天1~4个以上分支并行开发,每天都有分支需要集成和发版
& l* B$ C# |+ X- J% i/ v低频:同一项目,不一定每天都并行开发和发版,可能很长周期内都是串行开发# B5 I3 z- l& w8 Z( ?
那么,单从项目并行开发频率来看,哪款版本控制工具/系统更贴合各种频率的使用,集成和冲突解决更直观便捷易用,大家的依据又是什么?+ [; j% K+ l6 d/ ^* E4 T

* d6 J- B7 W2 R7 g三、从并行开发协同场景分解,看贴合度  G; @  i" t$ @% y6 }
项目二开,协同方式(定义假设条件)
+ y1 I. d; L' J/ O/ X% D0 D' }9 Q  k本地化协同开发:研发集中在一个固定场所,协同开发,涉及代码集成9 p& h/ a1 E( x$ G2 R' _
本地化独立开发:研发集中在一个固定场所,独立开发,独立交付6 `2 C1 ^7 l5 [' E. K: \
异地化协同开发:研发分散在全国各地,协同开发,涉及代码集成1 g) m2 Q& q" g/ X( |* [& X- P7 ~) w
异地化独立开发:研发分散在全国各地,独立开发,独立交付
, \8 s6 M! k( j" i0 e  ~4 {琳散的驻场开发:研发集中在一个固定场所,协同开发,偶尔需要到客户现场出差驻场开发
/ j/ F' ~9 G+ C' J5 F那么,单从协同方式看,哪些方式适用于集中式版本控制工具/系统,哪些适用于分布式版本控制工具/系统,哪款贴合度更高,大家的依据是什么?
" }; F5 m: e& `* Z  g( m$ V2 k$ u3 R6 b; w
如果我们将场景组合更复杂一些(从一、二、三中组合下条件),我们应该怎样合理评估甄别最适用的版本控制工具/系统?
$ V) W6 P7 p0 C- l) j9 z1 B: K( F' R6 \+ A; p
以上分解出的几个维度,仅仅针对配置管理实际应用中的源码版本控制选型...个人思考比较有限,也请大拿参与探讨不吝赐教
& U' q) [6 O9 U8 E1 u1 z" W$ t: u1 y9 e$ \
肯定还有很多前辈们有更多的建议或见解,希望能一起梳理出来,为以后初步接触的朋友铺铺路... 拜谢...; u6 @& e; m4 S& Z; m' O& I/ |. _

6 G: t& G4 h1 b" H, G
发表于 2017-12-27 11:16:41 | 显示全部楼层
不错哦。
回复 支持 反对

使用道具 举报

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

本版积分规则

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

GMT+8, 2018-4-20 17:30 , Processed in 0.060531 second(s), 6 queries , Gzip On, MemCache On.

Powered by SCMLife X3.4 Licensed

© 2001-2017 JoyShare.

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