SCMLife.com

 找回密码
 立即注册

QQ登录

只需一步,快速开始

扫一扫,访问微社区

查看: 1701|回复: 1

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

[复制链接]
发表于 2017-12-19 18:22:20 | 显示全部楼层 |阅读模式
0 t* V" Y* s, a* o: V+ y
背景起因:
; F/ ?: W- A. l' [有位新入坑的朋友,刚接触这个岗位,学习了一些配置管理的理论知识,不知道如何往下深入。
6 U$ r: G/ ~" N9 _, ~0 [& m  U" m变成了因为岗位上的事务需要被动响应而工作(比如权限管理,比如构建管理,比如发布管理,比如审计,比如持续集成等等),慢慢开始迷茫...
5 G1 u5 M+ F3 g1 Q$ b2 O, w8 y这个工作是否遇到瓶颈了,所掌握所了解就是全貌了?慢慢陷入达克效应中...
6 c  O  ~* |  H1 t这个讨论是希望所有从事这个岗位的朋友们,除理论知识外,还能从实际应用着手重新思考配置管理价值体现,这贴就以版本控制的选型开始吧../ N6 p$ R# `3 s

! j6 f' M6 M, I5 D议题:8 D1 |3 e0 u& u" s0 B
看到论坛里各类版本控制工具/系统的帖子都挺多,选择原因,可能如下:, A# x# B5 ]  c% Q- \* ]
1、公司一直在沿用这套版本控制工具/系统,由于需要保留源码历史记录,已经绑上贼船2 `! t0 Z3 R! T! T5 z) e) U
2、因为免费,因为不用再折腾没有新的成本投入,使用上也未遇见重大缺陷,就继续使用. s- h& s# N, U) P/ \
3、业界都在用这套版本控制工具/系统,网上可查资料多,所以我们也用了. P* T- h, Q+ q
4、根据认真评估甄别,确定的版本控制工具/系统  `5 |5 _/ \8 P8 h) |
  g7 S2 g5 z: {- H# R+ s
其中第4点,认真评估甄别,可有实际可操作的分解步骤?大家一起探讨一下?我先来几项; U1 _5 m0 L4 a. b+ V

8 Y' H1 g; m" ]( C1 H- b" O一、从源码规格分解,看性能
* `0 M+ ^& D+ A, L. @单个项目配置库源码规模(定义假设条件)
7 h$ v9 A" }3 ?- T9 Z: Y0 ]6 s$ T巨型:1g以上
* ^  s$ n/ M! d2 z5 u* I, N大型:500mb~999mb' d; k" j+ Q5 V% J8 A1 D5 Z
中型:300mb~499mb
8 |* n' P( Q: p% e, h小型:100mb~299mb, [% ?, C' ~3 m
微型:10mb~99mb
9 k. K* |$ `" c- N( [单个文件大小 50kb~5mb(碎文件多,目录层级深),研发规模500+,并发请求20~30
( z9 E9 g' @- Z7 w1 \那么,单从源码规格来看,哪些规格适合本地化管理,哪些规格适合云端托管?
! ?# k  y* a7 V: P7 w同硬件条件下,本地化管理的版本控制工具哪些性能更优(获取代码、集成代码、提交代码),大家的依据是什么?1 t, d) A4 p- q2 R, x  k
同费用配置下,云端托管的供应商哪些性能更优(获取代码、集成代码、提交代码),大家的依据又是什么?* v0 F, u8 N; O4 O2 y5 z7 s* @7 U
+ y3 q; `9 I9 H& x
二、从并行开发频率分解,看易用性' ]8 {0 v' t/ j8 R, |2 A
项目二次开发,并行开发频率(定义假设条件): g- u7 s/ i  {. i( d
超高频:同一项目,一天10个以上分支并行开发,每天都有分支需要集成和发版/ z/ s0 }& M4 M* R$ b
高频:同一项目,一天5~9个以上分支并行开发,每天都有分支需要集成和发版
7 ]4 y% Z4 x6 V中频:同一项目,一天1~4个以上分支并行开发,每天都有分支需要集成和发版
# o9 x# G# r( t7 _. |2 R/ V+ |低频:同一项目,不一定每天都并行开发和发版,可能很长周期内都是串行开发+ z, q; I& Z& U6 l
那么,单从项目并行开发频率来看,哪款版本控制工具/系统更贴合各种频率的使用,集成和冲突解决更直观便捷易用,大家的依据又是什么?& O" ]+ P( I8 X' U
0 o( J2 t# F  z/ u/ ]+ ~
三、从并行开发协同场景分解,看贴合度; H( T! |/ \7 }  N. n
项目二开,协同方式(定义假设条件)
) O# d  D+ q& i+ z本地化协同开发:研发集中在一个固定场所,协同开发,涉及代码集成: ]) J4 k: a7 T5 B
本地化独立开发:研发集中在一个固定场所,独立开发,独立交付
7 `" M! Q- r+ V! A# K0 `5 @异地化协同开发:研发分散在全国各地,协同开发,涉及代码集成
5 N; @$ u) C. B) Z8 V6 X+ _异地化独立开发:研发分散在全国各地,独立开发,独立交付7 G+ D- b6 N( k2 E7 F
琳散的驻场开发:研发集中在一个固定场所,协同开发,偶尔需要到客户现场出差驻场开发
# W1 ~4 y* w  C' Q* J那么,单从协同方式看,哪些方式适用于集中式版本控制工具/系统,哪些适用于分布式版本控制工具/系统,哪款贴合度更高,大家的依据是什么?9 Q8 {4 T  `! K7 @
& X. y5 t8 f/ h: C8 ^& w. Q2 `
如果我们将场景组合更复杂一些(从一、二、三中组合下条件),我们应该怎样合理评估甄别最适用的版本控制工具/系统?
& c# }' R# i  m. ^& C/ P; w+ y; R- |* ~/ R' D
以上分解出的几个维度,仅仅针对配置管理实际应用中的源码版本控制选型...个人思考比较有限,也请大拿参与探讨不吝赐教
& E  T5 }2 e$ v! a* e+ W+ ?2 ?$ i2 X8 |; f1 z
肯定还有很多前辈们有更多的建议或见解,希望能一起梳理出来,为以后初步接触的朋友铺铺路... 拜谢...3 s! v+ {7 R3 v$ p8 S
: q8 T* w* X8 c9 H. K5 V2 r
发表于 2017-12-27 11:16:41 | 显示全部楼层
不错哦。
回复 支持 反对

使用道具 举报

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

本版积分规则

关闭

SCMLife推荐上一条 /4 下一条

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

GMT+8, 2018-12-11 02:45 , Processed in 0.059523 second(s), 6 queries , Gzip On, MemCache On.

Powered by SCMLife X3.4 Licensed

© 2001-2017 JoyShare.

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