阿里云 MVP Meetup

持续集成的平衡之道

戚俊 / 南京路特软件 CTO

适用于 30—50 人团队

困境

持续集成、微服务

  • 成本
  • 管理
  • 效率

具体

  • 人力 需要专人进行代码的审查与合并
    • 不能过高期望测试人员
  • 资本 需要为持续集成的基础设施支付成本
  • 时间 会遇到各种持续集成工具链中的问题并大为苦恼
    • 技术选型、时间成本
  • 管理 找不到合适的姿势来维护企业/团队内的代码权限
    • Git 代码托管在公网时用户权限自动化调整长期缺位
  • 效率 发布一个大版本恨不得全公司的人到场

平衡:敏捷开发与持续集成

三个核心问题

  1. 需求及 Bug 如何尽快进入开发流程
    • 最终使用人群对客服反馈使用问题或者功能期望,如何尽快从客服转化到开发部门
  2. 开发成果如何快速试错
    • 产品经理增加功能时不知道用户是否接受
    • 传统软件行业注重契约合同,和试错有所冲突
  3. 如何依托持续集成快速迭代全流程
    • 现有开源产品只能完成技术整合,不一定符合目标(国内/本地)用户的使用习惯

现有流程的梳理

  • pull
  • checkout dev
  • 新建分支 dev-hanmeimei
    • 一个开发人员,一个分支,避免时间差污染
  • 开发完成后合并分支 dev-hanmeimeidev
  • 构建 dev 代码并测试
  • 测试通过,合并到 rc 分支
  • 构建 rc 代码并线测
    • 蓝绿部署、灰度发布、……
  • 测试通过,合并到 release 分支
  • 构建 release 代码并发布
    • 紧急 bug 修复时,创建 release-hanmeimei 分支

只做一个产品的公司是幸福的,但很可惜路特不是。从 agile 反而变成了慢吞吞的团队。

平衡:持续集成与工具链

  • (…/15)自建脚本:自己写一些脚本用来构建和部署
    • Java 和 .NET 构建为 binary,发布到 FTP,再定时让所有子机从 FTP 获取 binary
    • 出错率高
    • FTP 不安全
  • (15/16)CRP:切入了阿里的 CRP 平台,出于各种原因放弃了
    • CRP 当时不支持容器
  • Jenkins
    • 至少用了 3 台资源进行构建
    • 更新>构建 发展为 定时构建
  • RDC:重新迁移回阿里的 RDC 平台
    • 支持从项目管理、需求管理、bug 管理、跟踪、构建、部署,全流程支持

那些年踩过的工具坑

用户坑

每一个开源工具的部署,都意味着你需要对这个工具里的用户进行维护,形成一种碎片化的维护。

碎片数据坑

每一个工具都很强大,但是没有一个工具可以全流程完成持续集成所有的工具。所有日志分散在各处,形成各类数据孤岛。

运维坑

开源工具版本迭代 3 — 5 个月不更新,就落后大版本,再出现问题基本无法独立解决。

平衡:持续集成与架构

  • 双平台/多语言
    • .NET/PHP/Java, Windows 2008/Linux
  • 半容器化
    • .NET 的容器化接入当时不够成熟
  • 容器化/多语言
    • 将 .NET 重写为 PHP 或 .NET Core 版本
  • 容器化/微服务
    • 将所有的应用通过解耦拆分的方式,变成一个微服务进行部署集成
    • 慎重走向微服务,没有找到“舒服的姿势”,而且不如持续集成带来收益快且显著

演进路线图——一直在寻找平衡

  • 14 年开始调整持续集成架构
  • SVN 转 Git
  • 自定义脚本做构建及部署集成
  • 16 年业务初步调整为容器架构
  • 阵痛期,多个开源产品的拉锯抉择
  • 17 年末迁入 RDC,基本稳定

阶段性收获

  • 资源利用率提高,架构调整,节约 20-25 万成本,可以多招一个中级开发者/设计师
  • 钉钉可以全流程整合,尤其是权限管理,以及聊天记录自动整理识别
  • 多产品项目的持续集成通过 RDC 的自定义流水线,降低了中层成员的时间成本并提高了效率(开发者可以一路执行到构建,仅部署需要上级成员批准)

问答

团队沟通

  • 禅道等团队项目管理工具,根据需求做二次开发

微服务拆分原则

  • 可重用
  • 有弹性