SCMLife.com

 找回密码
 立即注册

QQ登录

只需一步,快速开始

扫一扫,访问微社区

查看: 2957|回复: 1

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

[复制链接]
发表于 2017-12-19 18:22:20 | 显示全部楼层 |阅读模式
: o) Z7 d# P) c( |' {
背景起因:% k5 i" N7 j1 c; ^# N& b7 k
有位新入坑的朋友,刚接触这个岗位,学习了一些配置管理的理论知识,不知道如何往下深入。
# w2 B3 F: A* `5 @变成了因为岗位上的事务需要被动响应而工作(比如权限管理,比如构建管理,比如发布管理,比如审计,比如持续集成等等),慢慢开始迷茫...
8 m2 p* l1 \" F& y9 s, S" r6 z& J这个工作是否遇到瓶颈了,所掌握所了解就是全貌了?慢慢陷入达克效应中...3 w) c% H' f; U2 B; }
这个讨论是希望所有从事这个岗位的朋友们,除理论知识外,还能从实际应用着手重新思考配置管理价值体现,这贴就以版本控制的选型开始吧../ L5 e( [. }8 Q
; U0 \5 ~/ l3 n1 M  H+ ]
议题:
) q1 u8 a6 N# e3 i看到论坛里各类版本控制工具/系统的帖子都挺多,选择原因,可能如下:
# J5 H, m; w! w% \7 ]1、公司一直在沿用这套版本控制工具/系统,由于需要保留源码历史记录,已经绑上贼船
+ F6 D: {: ?$ A8 C2、因为免费,因为不用再折腾没有新的成本投入,使用上也未遇见重大缺陷,就继续使用' c3 o( G4 y2 J" j
3、业界都在用这套版本控制工具/系统,网上可查资料多,所以我们也用了- a: B' {, i  Q
4、根据认真评估甄别,确定的版本控制工具/系统
' o/ ?$ `- b) G3 _  W1 z0 u) t6 m$ w1 R# @
其中第4点,认真评估甄别,可有实际可操作的分解步骤?大家一起探讨一下?我先来几项/ O1 g: U5 O& Q$ j% u$ g6 z

* n  ?. l/ J1 t% r4 n一、从源码规格分解,看性能
3 n. ~! ]# d. ~单个项目配置库源码规模(定义假设条件)
! F" B3 V. ?8 P9 z1 V巨型:1g以上
" T& m3 _% d3 f- M, c& ~  q2 j大型:500mb~999mb3 E; U2 i  [' i/ Z  B7 W
中型:300mb~499mb
0 w$ B4 ?; k. z小型:100mb~299mb+ Y( }+ Q& f1 Q0 }  R
微型:10mb~99mb% l0 h& Z9 k- P  i% ]$ {# `) ~
单个文件大小 50kb~5mb(碎文件多,目录层级深),研发规模500+,并发请求20~30: j" s" o6 W8 A) l6 M, d* j5 R: I
那么,单从源码规格来看,哪些规格适合本地化管理,哪些规格适合云端托管?9 \& f  ^+ Y2 o
同硬件条件下,本地化管理的版本控制工具哪些性能更优(获取代码、集成代码、提交代码),大家的依据是什么?
; H$ L- l0 G' S) G1 ^, F) S同费用配置下,云端托管的供应商哪些性能更优(获取代码、集成代码、提交代码),大家的依据又是什么?$ h. t8 P( F7 {% x7 h
1 H$ I7 o9 r' Q3 f/ {6 }+ v8 w
二、从并行开发频率分解,看易用性
' g9 K4 i( S3 ^项目二次开发,并行开发频率(定义假设条件)! e8 j' ?- @; ?7 \. U
超高频:同一项目,一天10个以上分支并行开发,每天都有分支需要集成和发版
  @9 e, |" J& u高频:同一项目,一天5~9个以上分支并行开发,每天都有分支需要集成和发版
, V, f' Q' L, n7 `% ~' M中频:同一项目,一天1~4个以上分支并行开发,每天都有分支需要集成和发版
  t' x2 R* m9 `  `; |* S+ s1 k低频:同一项目,不一定每天都并行开发和发版,可能很长周期内都是串行开发% A7 s5 z$ G7 f# l" }0 I+ K) B
那么,单从项目并行开发频率来看,哪款版本控制工具/系统更贴合各种频率的使用,集成和冲突解决更直观便捷易用,大家的依据又是什么?
/ s* j- m' x: w8 W: a( J% M" `
三、从并行开发协同场景分解,看贴合度
2 E. D8 s! L4 K项目二开,协同方式(定义假设条件)
) r1 c2 H- e) x本地化协同开发:研发集中在一个固定场所,协同开发,涉及代码集成9 p9 x# e/ w  k
本地化独立开发:研发集中在一个固定场所,独立开发,独立交付. [3 @" p7 @9 U" G
异地化协同开发:研发分散在全国各地,协同开发,涉及代码集成, z8 e9 A- b! t4 _6 n
异地化独立开发:研发分散在全国各地,独立开发,独立交付
" ]- m9 o4 b+ E琳散的驻场开发:研发集中在一个固定场所,协同开发,偶尔需要到客户现场出差驻场开发0 p* q3 X% u0 l+ ^
那么,单从协同方式看,哪些方式适用于集中式版本控制工具/系统,哪些适用于分布式版本控制工具/系统,哪款贴合度更高,大家的依据是什么?
1 {$ w( G; F: ?* ]+ p5 K+ U9 F6 Z0 q4 Z* b& c
如果我们将场景组合更复杂一些(从一、二、三中组合下条件),我们应该怎样合理评估甄别最适用的版本控制工具/系统?( Z5 t6 r6 m1 O

5 |6 a8 z# ^, g; P以上分解出的几个维度,仅仅针对配置管理实际应用中的源码版本控制选型...个人思考比较有限,也请大拿参与探讨不吝赐教
. z  Y  ^4 a4 O- P+ m, X" g: Z% y2 N" N) i' b. z1 ^
肯定还有很多前辈们有更多的建议或见解,希望能一起梳理出来,为以后初步接触的朋友铺铺路... 拜谢.... ~+ J- P2 @& h, G: U+ ~

: e' [2 ?( ?  G6 C1 c; \3 b# B
发表于 2017-12-27 11:16:41 | 显示全部楼层
不错哦。
回复 支持 反对

使用道具 举报

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

本版积分规则

关闭

SCMLife推荐上一条 /5 下一条

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

GMT+8, 2020-1-25 12:57 , Processed in 0.067008 second(s), 7 queries , Gzip On, MemCache On.

Powered by SCMLife X3.4 Licensed

© 2001-2017 JoyShare.

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