SCMLife.com

 找回密码
 立即注册

QQ登录

只需一步,快速开始

扫一扫,访问微社区

查看: 308|回复: 1

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

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

: L" w9 H2 w) _( Q背景起因:0 d9 h. c; h  d3 {, |* G
有位新入坑的朋友,刚接触这个岗位,学习了一些配置管理的理论知识,不知道如何往下深入。' E2 l, N6 J% E6 P; S1 m
变成了因为岗位上的事务需要被动响应而工作(比如权限管理,比如构建管理,比如发布管理,比如审计,比如持续集成等等),慢慢开始迷茫...
1 U. H1 P/ w. B$ Q; K! U( N这个工作是否遇到瓶颈了,所掌握所了解就是全貌了?慢慢陷入达克效应中...
! [8 [; A7 I0 S0 W- D  H这个讨论是希望所有从事这个岗位的朋友们,除理论知识外,还能从实际应用着手重新思考配置管理价值体现,这贴就以版本控制的选型开始吧..
1 b, x9 {# }& }; }
, E; [2 Z! c9 G0 M$ K7 D) s议题:3 h9 _" `/ }9 ^1 U& S( B$ ~- e
看到论坛里各类版本控制工具/系统的帖子都挺多,选择原因,可能如下:
8 F9 W3 Z' n  Z& X8 W( t1、公司一直在沿用这套版本控制工具/系统,由于需要保留源码历史记录,已经绑上贼船
9 G& A3 C& Y6 ^1 a; m( i2、因为免费,因为不用再折腾没有新的成本投入,使用上也未遇见重大缺陷,就继续使用1 w" {3 H0 [/ v+ K* B5 X
3、业界都在用这套版本控制工具/系统,网上可查资料多,所以我们也用了
. D) _+ N( [8 c' x4、根据认真评估甄别,确定的版本控制工具/系统
. Q' t4 m/ `: P. W  W. g& ]& q: Y  `0 I+ t4 L
其中第4点,认真评估甄别,可有实际可操作的分解步骤?大家一起探讨一下?我先来几项1 ^( r4 d: x" a
8 |" L, t, ^4 v; w2 s" B1 ?
一、从源码规格分解,看性能' z3 g% l% }6 i5 ~
单个项目配置库源码规模(定义假设条件)
$ F1 G5 X7 m" ?, \( V巨型:1g以上( S/ b2 h# f2 ?0 B1 n0 H
大型:500mb~999mb0 S' j) H  u' h$ o
中型:300mb~499mb
: Z" I  B# I  x& s$ H& U+ G: m8 A% w小型:100mb~299mb
% j, B' T8 t9 m+ r2 N微型:10mb~99mb# \2 J- \0 k9 {
单个文件大小 50kb~5mb(碎文件多,目录层级深),研发规模500+,并发请求20~301 @' g, ?9 [) m
那么,单从源码规格来看,哪些规格适合本地化管理,哪些规格适合云端托管?0 E8 J( E; r& j. r& x. D
同硬件条件下,本地化管理的版本控制工具哪些性能更优(获取代码、集成代码、提交代码),大家的依据是什么?
7 [( f5 F5 `3 M: @: w同费用配置下,云端托管的供应商哪些性能更优(获取代码、集成代码、提交代码),大家的依据又是什么?- o. g" @! B& z, C

, O" t2 v. b# B二、从并行开发频率分解,看易用性
3 x- ]0 G$ \8 A; l项目二次开发,并行开发频率(定义假设条件)
% n/ z0 i/ H! f/ m% ^" ~+ f6 Z超高频:同一项目,一天10个以上分支并行开发,每天都有分支需要集成和发版  h8 J% Z) M, q7 S2 m! `
高频:同一项目,一天5~9个以上分支并行开发,每天都有分支需要集成和发版
0 q6 W7 Z/ C  Q( r3 O" A9 C4 f中频:同一项目,一天1~4个以上分支并行开发,每天都有分支需要集成和发版% P' S5 k- x( n( F1 \  |
低频:同一项目,不一定每天都并行开发和发版,可能很长周期内都是串行开发
" d% e: z- G$ }2 P+ D; `% c那么,单从项目并行开发频率来看,哪款版本控制工具/系统更贴合各种频率的使用,集成和冲突解决更直观便捷易用,大家的依据又是什么?) |; w, ^2 R5 a( k$ [; a9 K
9 X4 @- ^- I# C( p
三、从并行开发协同场景分解,看贴合度1 z6 L' T" S& o0 _, e
项目二开,协同方式(定义假设条件)
, u: h2 J' [0 a+ V本地化协同开发:研发集中在一个固定场所,协同开发,涉及代码集成
5 H- k& B; z" U' b3 j3 I& R" G本地化独立开发:研发集中在一个固定场所,独立开发,独立交付
4 o4 U# W. K3 L, Z& {0 g异地化协同开发:研发分散在全国各地,协同开发,涉及代码集成
. L7 ]: @8 I' ~& q& O: j异地化独立开发:研发分散在全国各地,独立开发,独立交付9 |  v& @! |7 X- r% r
琳散的驻场开发:研发集中在一个固定场所,协同开发,偶尔需要到客户现场出差驻场开发* K2 a# n1 _1 ]
那么,单从协同方式看,哪些方式适用于集中式版本控制工具/系统,哪些适用于分布式版本控制工具/系统,哪款贴合度更高,大家的依据是什么?
  R# O+ I4 [6 y0 R* ^" }
* I8 I- p6 c( x0 l+ V7 T' S6 |如果我们将场景组合更复杂一些(从一、二、三中组合下条件),我们应该怎样合理评估甄别最适用的版本控制工具/系统?( V) z# ?" P" S' b8 A$ T! _4 @* y
1 E# d! p; N  n
以上分解出的几个维度,仅仅针对配置管理实际应用中的源码版本控制选型...个人思考比较有限,也请大拿参与探讨不吝赐教
  i$ r0 x2 \" ?. o4 e& O' `- w0 x, c4 z4 u9 G9 r& [
肯定还有很多前辈们有更多的建议或见解,希望能一起梳理出来,为以后初步接触的朋友铺铺路... 拜谢.... ^8 d9 i1 E: y& r  _

0 m+ M8 Z( d( y
发表于 2017-12-27 11:16:41 | 显示全部楼层
不错哦。
回复 支持 反对

使用道具 举报

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

本版积分规则

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

GMT+8, 2018-1-21 07:56 , Processed in 0.061325 second(s), 6 queries , Gzip On, MemCache On.

Powered by SCMLife X3.4 Licensed

© 2001-2017 JoyShare.

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