SCMLife.com

 找回密码
 立即注册

QQ登录

只需一步,快速开始

扫一扫,访问微社区

查看: 2327|回复: 1

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

[复制链接]
发表于 2017-12-19 18:22:20 | 显示全部楼层 |阅读模式
7 I, L, S. s! R
背景起因:
! e; d: L/ X& B, M# Q9 l: \$ \! X有位新入坑的朋友,刚接触这个岗位,学习了一些配置管理的理论知识,不知道如何往下深入。9 M/ I. H- y( I1 o8 [* l/ z
变成了因为岗位上的事务需要被动响应而工作(比如权限管理,比如构建管理,比如发布管理,比如审计,比如持续集成等等),慢慢开始迷茫...5 t/ q: b0 g: M* W3 o+ o- x
这个工作是否遇到瓶颈了,所掌握所了解就是全貌了?慢慢陷入达克效应中...1 G, Y) p" w8 t+ f: O) o
这个讨论是希望所有从事这个岗位的朋友们,除理论知识外,还能从实际应用着手重新思考配置管理价值体现,这贴就以版本控制的选型开始吧..4 Z" N' ~" J* Y5 g8 i) Y8 O
- S8 C+ y) B. z4 X" H/ h% i8 s: Z
议题:
; V  Y& K1 v, M' \' ]+ t5 i看到论坛里各类版本控制工具/系统的帖子都挺多,选择原因,可能如下:1 Q* C( b$ w1 I5 A4 d
1、公司一直在沿用这套版本控制工具/系统,由于需要保留源码历史记录,已经绑上贼船- h* i8 l( H6 [8 v
2、因为免费,因为不用再折腾没有新的成本投入,使用上也未遇见重大缺陷,就继续使用
* e# c( B  k5 j+ m0 d) H3、业界都在用这套版本控制工具/系统,网上可查资料多,所以我们也用了
* D5 f$ ]* W5 o5 r* M4、根据认真评估甄别,确定的版本控制工具/系统
4 W, s* m* n6 i9 Y3 W# ^/ M: k2 c+ U% ?$ @8 x/ x) U
其中第4点,认真评估甄别,可有实际可操作的分解步骤?大家一起探讨一下?我先来几项- I6 E5 c! q5 c3 h3 t

" i5 Z% {; c+ B2 ]; }5 m' @2 y4 }" ^一、从源码规格分解,看性能
! I7 Y% a9 }( W. m6 R7 m单个项目配置库源码规模(定义假设条件)
2 l  f* x$ z1 {% _" ~" @6 L/ g/ `巨型:1g以上, X$ W7 V5 |# \& n
大型:500mb~999mb
% Q& d, R" h% z: {) k1 e3 `: c中型:300mb~499mb& Y5 ?+ P3 w  \6 [# s, G1 Z
小型:100mb~299mb
1 {7 D& y! F: D9 ~$ v微型:10mb~99mb
( L8 X- o9 `* C9 H8 C5 O单个文件大小 50kb~5mb(碎文件多,目录层级深),研发规模500+,并发请求20~30) E" u9 r6 B, D
那么,单从源码规格来看,哪些规格适合本地化管理,哪些规格适合云端托管?( p0 ]( z5 d, Z- Y
同硬件条件下,本地化管理的版本控制工具哪些性能更优(获取代码、集成代码、提交代码),大家的依据是什么?
0 M' n! W8 @8 f4 b5 x同费用配置下,云端托管的供应商哪些性能更优(获取代码、集成代码、提交代码),大家的依据又是什么?
. ]1 l( s* X# j" ?0 e& N) C' C6 j  `$ Y! q* ]5 Q# ^
二、从并行开发频率分解,看易用性5 H0 V! b$ c/ l7 u7 M! d
项目二次开发,并行开发频率(定义假设条件)
0 G# Q8 v, p& M# k" i. _+ E8 c6 i4 i超高频:同一项目,一天10个以上分支并行开发,每天都有分支需要集成和发版
1 D- Z5 f" U8 r/ r; y8 o9 S高频:同一项目,一天5~9个以上分支并行开发,每天都有分支需要集成和发版, N2 r4 Z$ a# A3 L1 W) r
中频:同一项目,一天1~4个以上分支并行开发,每天都有分支需要集成和发版
. y6 y/ s# v! e! F* s" ~. e7 t  [低频:同一项目,不一定每天都并行开发和发版,可能很长周期内都是串行开发
1 z& g7 W- V8 y9 R3 c那么,单从项目并行开发频率来看,哪款版本控制工具/系统更贴合各种频率的使用,集成和冲突解决更直观便捷易用,大家的依据又是什么?# ^$ {* u/ n% B9 p

! ^  d: A& J: u( p, W/ @三、从并行开发协同场景分解,看贴合度  F5 S; Y5 o2 q+ T4 p' q7 g
项目二开,协同方式(定义假设条件)' ]1 A7 B: P+ g0 z! |
本地化协同开发:研发集中在一个固定场所,协同开发,涉及代码集成* v4 b( T+ j' }' i( L# x
本地化独立开发:研发集中在一个固定场所,独立开发,独立交付1 N4 \3 `- j! N# `8 w
异地化协同开发:研发分散在全国各地,协同开发,涉及代码集成+ Z5 z5 {; M- `# i4 f
异地化独立开发:研发分散在全国各地,独立开发,独立交付
- i5 H3 V. Q, c琳散的驻场开发:研发集中在一个固定场所,协同开发,偶尔需要到客户现场出差驻场开发$ I8 G% F9 @% v* s" r
那么,单从协同方式看,哪些方式适用于集中式版本控制工具/系统,哪些适用于分布式版本控制工具/系统,哪款贴合度更高,大家的依据是什么?
" @2 t* X. g( m0 w6 F8 p
. o3 H/ H) y. Z. z) ]4 _1 [! |4 H2 ]如果我们将场景组合更复杂一些(从一、二、三中组合下条件),我们应该怎样合理评估甄别最适用的版本控制工具/系统?
* ~3 y* @& h  G
" H1 L( M% t, ]0 s8 g6 S以上分解出的几个维度,仅仅针对配置管理实际应用中的源码版本控制选型...个人思考比较有限,也请大拿参与探讨不吝赐教: g, \, ^3 J6 ?( X

+ t, f; l( u: a! V! u肯定还有很多前辈们有更多的建议或见解,希望能一起梳理出来,为以后初步接触的朋友铺铺路... 拜谢...  U+ c. U  [0 N. i7 J

& |$ E2 q  S/ S9 t% r' P
发表于 2017-12-27 11:16:41 | 显示全部楼层
不错哦。
回复 支持 反对

使用道具 举报

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

本版积分规则

关闭

SCMLife推荐上一条 /4 下一条

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

GMT+8, 2019-4-24 02:56 , Processed in 0.075109 second(s), 6 queries , Gzip On, MemCache On.

Powered by SCMLife X3.4 Licensed

© 2001-2017 JoyShare.

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