SCMLife.com

 找回密码
 立即注册

QQ登录

只需一步,快速开始

扫一扫,访问微社区

查看: 2545|回复: 1

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

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

# t" T  O: d5 A* j: o$ l+ }* @) T背景起因:0 \  C+ u9 I: j. h1 A+ x  g
有位新入坑的朋友,刚接触这个岗位,学习了一些配置管理的理论知识,不知道如何往下深入。
, M$ C+ Z( k) g' e$ B" L  s5 f0 @8 a变成了因为岗位上的事务需要被动响应而工作(比如权限管理,比如构建管理,比如发布管理,比如审计,比如持续集成等等),慢慢开始迷茫...# ~1 o: N3 {) y3 J( |
这个工作是否遇到瓶颈了,所掌握所了解就是全貌了?慢慢陷入达克效应中..." r4 \0 K8 M$ m/ R3 [7 e/ u5 ^# B( G
这个讨论是希望所有从事这个岗位的朋友们,除理论知识外,还能从实际应用着手重新思考配置管理价值体现,这贴就以版本控制的选型开始吧..5 }2 X6 i# ?* c( [
8 l& ~, B' c7 c1 S* E. o
议题:
! y5 @! }) S- u9 B- s2 m看到论坛里各类版本控制工具/系统的帖子都挺多,选择原因,可能如下:* V* o3 V0 U5 w6 p6 p" B6 r
1、公司一直在沿用这套版本控制工具/系统,由于需要保留源码历史记录,已经绑上贼船
3 X0 l7 `$ O3 D2、因为免费,因为不用再折腾没有新的成本投入,使用上也未遇见重大缺陷,就继续使用8 A/ N9 Q( P8 E5 G
3、业界都在用这套版本控制工具/系统,网上可查资料多,所以我们也用了
8 a+ F0 |, R; h) M3 v3 P$ M, L; B4、根据认真评估甄别,确定的版本控制工具/系统4 u. ]4 q/ f+ a- I6 @. b+ f

" V7 m# J! V) ]其中第4点,认真评估甄别,可有实际可操作的分解步骤?大家一起探讨一下?我先来几项
& ~4 g% J7 w0 h7 s+ Y* @
; S( f. P9 l+ i/ B+ v/ c) d& C一、从源码规格分解,看性能
3 O, s! {; F' U  G, S* X% i单个项目配置库源码规模(定义假设条件)
; l$ J: v- Z, Q2 Y+ U  O巨型:1g以上
0 H  x- ]3 e& `4 M大型:500mb~999mb. L% f: i* O+ h0 o" {" ]& _
中型:300mb~499mb
$ E! B% P9 a' N5 [9 Y小型:100mb~299mb
. s, h' K" i9 H3 b8 Y微型:10mb~99mb
& R% ?- J( \7 {: v8 H2 K  V& C单个文件大小 50kb~5mb(碎文件多,目录层级深),研发规模500+,并发请求20~30
9 G, T. z0 d& q那么,单从源码规格来看,哪些规格适合本地化管理,哪些规格适合云端托管?; ~9 d' j4 |, s* |& U
同硬件条件下,本地化管理的版本控制工具哪些性能更优(获取代码、集成代码、提交代码),大家的依据是什么?6 m9 I, V- c$ g1 D% G, q' k
同费用配置下,云端托管的供应商哪些性能更优(获取代码、集成代码、提交代码),大家的依据又是什么?2 e4 E! e# `8 n: H2 y
( Q$ ~9 s/ A8 L
二、从并行开发频率分解,看易用性
( h3 l  b+ T" y- U9 t项目二次开发,并行开发频率(定义假设条件)
8 X- o2 d$ i1 Z: U9 X3 `3 u超高频:同一项目,一天10个以上分支并行开发,每天都有分支需要集成和发版
; N; R! G: @2 W  v/ U) K6 |, Y2 i8 C高频:同一项目,一天5~9个以上分支并行开发,每天都有分支需要集成和发版2 s" G( F9 ]1 V9 }0 N
中频:同一项目,一天1~4个以上分支并行开发,每天都有分支需要集成和发版
! w# W1 u0 F" A' l低频:同一项目,不一定每天都并行开发和发版,可能很长周期内都是串行开发6 L+ |# H# z$ C
那么,单从项目并行开发频率来看,哪款版本控制工具/系统更贴合各种频率的使用,集成和冲突解决更直观便捷易用,大家的依据又是什么?# {4 C6 H2 l! n3 A% @! t+ y
1 d( |9 r# c8 |" `' W
三、从并行开发协同场景分解,看贴合度
6 R% Z! T5 t! I: n4 p; U项目二开,协同方式(定义假设条件)' L& j/ O! Y) g7 G# T6 h
本地化协同开发:研发集中在一个固定场所,协同开发,涉及代码集成
9 w8 C% r! a' V2 G- E本地化独立开发:研发集中在一个固定场所,独立开发,独立交付9 O- M/ L/ H7 R
异地化协同开发:研发分散在全国各地,协同开发,涉及代码集成3 o5 Y+ b2 ~4 B8 ?7 X
异地化独立开发:研发分散在全国各地,独立开发,独立交付3 f/ b( m/ `  N2 s
琳散的驻场开发:研发集中在一个固定场所,协同开发,偶尔需要到客户现场出差驻场开发7 N/ P; ^, Y1 m, \* i1 u6 }0 Q+ f
那么,单从协同方式看,哪些方式适用于集中式版本控制工具/系统,哪些适用于分布式版本控制工具/系统,哪款贴合度更高,大家的依据是什么?% s1 x% ^' M! k7 w8 k9 W% z3 f3 j- M
0 ]# e! [" h  B: V- ~8 s
如果我们将场景组合更复杂一些(从一、二、三中组合下条件),我们应该怎样合理评估甄别最适用的版本控制工具/系统?) S* }( c$ ~( G+ [1 C

- [" u( T# n9 l% t; v+ ?9 q以上分解出的几个维度,仅仅针对配置管理实际应用中的源码版本控制选型...个人思考比较有限,也请大拿参与探讨不吝赐教0 k1 n$ t! p/ h. X; Y# \8 i7 y6 i

) r* G5 ?0 Z' R肯定还有很多前辈们有更多的建议或见解,希望能一起梳理出来,为以后初步接触的朋友铺铺路... 拜谢...
3 n0 [- R8 d- R1 j' p) L$ Y6 c% X5 O- p7 x
发表于 2017-12-27 11:16:41 | 显示全部楼层
不错哦。
回复 支持 反对

使用道具 举报

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

本版积分规则

关闭

SCMLife推荐上一条 /4 下一条

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

GMT+8, 2019-6-25 20:40 , Processed in 0.057322 second(s), 6 queries , Gzip On, MemCache On.

Powered by SCMLife X3.4 Licensed

© 2001-2017 JoyShare.

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