网页资讯视频图片知道文库贴吧地图采购
进入贴吧全吧搜索

 
 
 
日一二三四五六
       
       
       
       
       
       

签到排名:今日本吧第个签到,

本吧因你更精彩,明天继续来努力!

本吧签到人数:0

一键签到
成为超级会员,使用一键签到
一键签到
本月漏签0次!
0
成为超级会员,赠送8张补签卡
如何使用?
点击日历上漏签日期,即可进行补签。
连续签到:天  累计签到:天
0
超级会员单次开通12个月以上,赠送连续签到卡3张
使用连续签到卡
06月06日漏签0天
企业网盘吧 关注:332贴子:800
  • 看贴

  • 图片

  • 吧主推荐

  • 游戏

  • 8回复贴,共1页
<<返回企业网盘吧
>0< 加载中...

联想企业网盘:SaaS服务集群化持续交付实践

  • 只看楼主
  • 收藏

  • 回复
  • TCDMiao
  • 1L喂熊
    1
该楼层疑似违规已被系统折叠 隐藏此楼查看此楼
1 前言
当代信息技术飞速发展,软件和系统的代码规模都变得越来越大,而且组件众多,依赖繁复,每次新版本的发布都仿佛是乘坐一次无座的绿皮车长途夜行,疲惫不堪。软件交付是一个复杂的工程,涉及到软件开发的各个细节,其中任何一环出现问题,都会导致软件不能及时交付,或者交付的质量堪忧。
从企业的角度来讲,如何利用更科学的工具、更科学的流程来提高产品质量,提升客户满意度,是刚需。从员工角度来讲,生命里值得追求的事情很多,不能把宝贵的时间浪费在一些机械的、重复的事情上面。
联想企业网盘从2007年开始面向企业客户提供专业的云存储服务,10年来服务了250000+企业。软件的更新迭代司空见惯,联想企业网盘就是由成百上千台服务器组成的,是一个非常复杂的互联网应用,仅仅在服务端就有几十个模块协同工作,加上各种客户端,需要使用不同的编译发布环境,有时候需要单独模块发布,有时候需要多个模块联合发布,使得每次的升级情况都非常复杂。曾经经历过一次大版本的升级迭代,运维和研发团队不眠不休的工作了40多个小时,既影响了用户的服务,也使得团队疲惫不堪。类似的经历,使得我们思考如何通过技术革新来解决这一难题,能够把我们的工程师们从简单劳动中解放出来,这样在未来面对更大规模的集群的时候,才能够游刃有余。
缩短上线时间,提高上线准确度,是我们建设这个系统的初衷。


  • TCDMiao
  • 1L喂熊
    1
该楼层疑似违规已被系统折叠 隐藏此楼查看此楼

2 问题
先让我们借用一张图(来源于 thoughtworks 官方文档)来回顾一下软件发布的一个完整的流程:


2025-06-06 05:00:25
广告
  • TCDMiao
  • 1L喂熊
    1
该楼层疑似违规已被系统折叠 隐藏此楼查看此楼
整个过程中,代码管理,集成和测试,发布上线是3个主要的环节。我们所有的问题都集中在这3个环节当中。
1、代码管理
代码管理混乱是一个研发团队的常见问题,研发的过程中,代码的分支设计不合理,分支过多或者过少,分支依赖混乱,权限控制缺失,完全靠人治,没有代码审核。
2、集成和测试
从研发环境到测试环境,都没有统一规范的部署环境,研发团队直接给测试出版本(野版本),因为编译环境,人员水平的差异会导致各种莫名其妙(有时候很低级)的问题,极大的影响了测试的效率和准确度。
3、上线交付
代码最终部署到生产环境的时候,需要运维人员和研发人员频繁手工操作,费时费力,还容易出错,整个过程不可重复且没有记录,回滚操作复杂,有时候甚至是无法回滚的,一旦是上线出现错误,对我们用户的影响就是非常恶劣的。


  • TCDMiao
  • 1L喂熊
    1
该楼层疑似违规已被系统折叠 隐藏此楼查看此楼
3.1 代码管理
代码是软件交付过程的源头,所以合理的规划与管理尤为重要。
3.1.1 代码仓库
早期,我们所有研发人员的代码都存放在一个SVN 库里,分支和 Tag 散布在各个模块的子目录里。SVN是很好的一个工具,但是太灵活了,要大家严格遵守纪律,但是更多时候要靠大家自觉,但是人总是会有松懈的时候。一旦有人不守纪律,对于后来者就是一个苦不堪言过程。
所以我们的第一步,就是把SVN 迁移至 Git。按照模块拆分为单独的库,每个模块单独授权,统一分支模型。仓库软件用的Gerrit,它原本是代码审核工具,拥有强大的权限管理系统,Git仓库只是附带的功能。
其实在从SVN迁移到Git的时候,有很多工程师会有疑问,为什么迁移到Git?不是 SVN 不好,也不是为了追逐技术潮流,而是后面的自动化工作(包括代码审核工具)用Git 更方便,当然 Git 强大的分支功能以及分布式也是一个重要原因。


  • TCDMiao
  • 1L喂熊
    1
该楼层疑似违规已被系统折叠 隐藏此楼查看此楼
3.1.2 分支设计
分支我们参考比较常见的一个Git 分支模型(参考链接),针对我们自己的需求做了一些调整,如下图:


  • TCDMiao
  • 1L喂熊
    1
该楼层疑似违规已被系统折叠 隐藏此楼查看此楼
1.1.1 审核
代码是产品质量的源头,代码质量不行,其他再多辅助手段都没用。代码审核是保证代码质量至关重要的一环。只要团队人员数大于一个就应该推行代码审核。
代码审核有两种模式:
l 集成前审核(prereview)
顾名思义,在代码合并至目标分支前进行代码审核,有问题改,改完再继续审核,审核通过则集成进目标分支,这一类审核的代表工具软件有:Github,Gerrit,其中 Github 是以分支为单位进行审核,Gerrit 以提交为单位进行审核。
l 集成后审核(postreview)
先合并代码,然后进行审核,有问题只能用新的提交来修复了,这一类审核的代表工具软件(其实这两款软件也支持 pre review):reviewboard,phabricator。此种方式容易导致目标分支不稳定,所以一般不建议。
我们采用的是第一种集成前审核的方式,工具软件用的 Gerrit,以提交为单位,强制审核过后再合并至目标分支(当然这个过程是自动的)。
好了,话不多说,有图有真相,下图是我们的代码提交工作流:


登录百度账号

扫二维码下载贴吧客户端

下载贴吧APP
看高清直播、视频!
  • 贴吧页面意见反馈
  • 违规贴吧举报反馈通道
  • 贴吧违规信息处理公示
  • 8回复贴,共1页
<<返回企业网盘吧
分享到:
©2025 Baidu贴吧协议|隐私政策|吧主制度|意见反馈|网络谣言警示