SCMLife.com

 找回密码
 立即注册

QQ登录

只需一步,快速开始

扫一扫,访问微社区

查看: 1425|回复: 1

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

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

+ j& p" C+ Q- y4 G# M背景起因:* W: t% L# P0 I. m9 b
有位新入坑的朋友,刚接触这个岗位,学习了一些配置管理的理论知识,不知道如何往下深入。
% H# S  r! q/ T* l) z6 S1 E/ M% P变成了因为岗位上的事务需要被动响应而工作(比如权限管理,比如构建管理,比如发布管理,比如审计,比如持续集成等等),慢慢开始迷茫...
# v4 O- h9 z9 I- ]8 C% p% L# i这个工作是否遇到瓶颈了,所掌握所了解就是全貌了?慢慢陷入达克效应中...
6 C7 r3 d, S) t9 g这个讨论是希望所有从事这个岗位的朋友们,除理论知识外,还能从实际应用着手重新思考配置管理价值体现,这贴就以版本控制的选型开始吧..$ v3 o, [& i' X6 N

. J! T6 L( a1 w. _( H7 G议题:
% v% g9 h/ M6 B3 M+ a- y看到论坛里各类版本控制工具/系统的帖子都挺多,选择原因,可能如下:
7 j6 \% N9 A0 h$ y0 t1 D$ u  ~1、公司一直在沿用这套版本控制工具/系统,由于需要保留源码历史记录,已经绑上贼船
8 u' A- u: y* {( s4 o2、因为免费,因为不用再折腾没有新的成本投入,使用上也未遇见重大缺陷,就继续使用
7 O( m% j% i- s3 k. |( Q' L3、业界都在用这套版本控制工具/系统,网上可查资料多,所以我们也用了
( q+ Y9 y' I1 ]- x0 x4、根据认真评估甄别,确定的版本控制工具/系统. t1 L; A  M7 h  l9 X1 r
; v# K0 C/ w# n; E' B1 L5 |
其中第4点,认真评估甄别,可有实际可操作的分解步骤?大家一起探讨一下?我先来几项
) C2 m, B0 n* J& q% F6 r' A) Y6 z3 Y) _8 }% h, \, m. I! c( P
一、从源码规格分解,看性能& Z: x1 |' e5 t$ i# n1 _# S- h- V
单个项目配置库源码规模(定义假设条件)8 L, x7 C0 g' J0 ]9 o
巨型:1g以上
4 D, [4 e# g' v  |0 Q大型:500mb~999mb' c" j0 _& L0 h+ D2 U5 {* a
中型:300mb~499mb! K5 `) j$ P- U& ~( L
小型:100mb~299mb
# q) C2 o% E) a4 X% q+ Q8 f微型:10mb~99mb+ j1 b( E; M, g
单个文件大小 50kb~5mb(碎文件多,目录层级深),研发规模500+,并发请求20~30
9 R6 S; @/ U. @那么,单从源码规格来看,哪些规格适合本地化管理,哪些规格适合云端托管?
/ M5 J' Y( N4 P同硬件条件下,本地化管理的版本控制工具哪些性能更优(获取代码、集成代码、提交代码),大家的依据是什么?$ _$ `4 e0 b$ k. M
同费用配置下,云端托管的供应商哪些性能更优(获取代码、集成代码、提交代码),大家的依据又是什么?8 n8 k4 Q" ?0 \9 t4 w

4 h' N5 u8 K& H2 J1 e二、从并行开发频率分解,看易用性4 k" W( D9 m1 ?* X
项目二次开发,并行开发频率(定义假设条件)- M. G6 A$ |; n8 L, s* r( g
超高频:同一项目,一天10个以上分支并行开发,每天都有分支需要集成和发版" V8 Z) y, ]( K. j  l- {
高频:同一项目,一天5~9个以上分支并行开发,每天都有分支需要集成和发版
+ k4 s) t/ r& L% v中频:同一项目,一天1~4个以上分支并行开发,每天都有分支需要集成和发版
( X+ }6 ^" W, v  [低频:同一项目,不一定每天都并行开发和发版,可能很长周期内都是串行开发: _& o$ A1 G& e4 w9 F7 y, i0 r6 g
那么,单从项目并行开发频率来看,哪款版本控制工具/系统更贴合各种频率的使用,集成和冲突解决更直观便捷易用,大家的依据又是什么?- H4 q/ T) L  y8 E
! @7 e) e4 Y! ~
三、从并行开发协同场景分解,看贴合度2 w' c* V# e8 g0 \8 _8 }# Q
项目二开,协同方式(定义假设条件)- o0 t* r1 k, W! m$ }# }& E( _+ v0 B
本地化协同开发:研发集中在一个固定场所,协同开发,涉及代码集成0 I3 M- B. _* v- G
本地化独立开发:研发集中在一个固定场所,独立开发,独立交付( y; u" s  [, y/ {: |) c5 Y
异地化协同开发:研发分散在全国各地,协同开发,涉及代码集成
! U* ~+ I5 A8 m异地化独立开发:研发分散在全国各地,独立开发,独立交付: C" W$ T  {$ w3 E
琳散的驻场开发:研发集中在一个固定场所,协同开发,偶尔需要到客户现场出差驻场开发
8 P) D" m& S; O, R' ]) j/ Z那么,单从协同方式看,哪些方式适用于集中式版本控制工具/系统,哪些适用于分布式版本控制工具/系统,哪款贴合度更高,大家的依据是什么?0 Z, U- T* z: c! E+ Q- J

) L, G6 B9 M- l7 G. u( s如果我们将场景组合更复杂一些(从一、二、三中组合下条件),我们应该怎样合理评估甄别最适用的版本控制工具/系统?
" \5 D. R$ p& n$ s- K/ }
& Y" j0 p8 ?7 c$ S& [7 Z8 p. z以上分解出的几个维度,仅仅针对配置管理实际应用中的源码版本控制选型...个人思考比较有限,也请大拿参与探讨不吝赐教
, Z% C. P$ d4 |! ^( @
4 }' {7 H/ R, I肯定还有很多前辈们有更多的建议或见解,希望能一起梳理出来,为以后初步接触的朋友铺铺路... 拜谢...
# y0 o4 K& X6 ?! n
/ E0 b& i* \+ E0 x. s9 n
发表于 2017-12-27 11:16:41 | 显示全部楼层
不错哦。
回复 支持 反对

使用道具 举报

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

本版积分规则

关闭

SCMLife推荐上一条 /3 下一条

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

GMT+8, 2018-8-17 15:04 , Processed in 0.063327 second(s), 6 queries , Gzip On, MemCache On.

Powered by SCMLife X3.4 Licensed

© 2001-2017 JoyShare.

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