ToB产品DevOps实践(三)

215 阅读2分钟

持续创作,加速成长!这是我参与「掘金日新计划 · 6 月更文挑战」的第15天,点击查看活动详情

2 向前看是持续集成,向后看是持续交付

  • 持续集成关注的是各个集成单元之前最新版本的集成问题,即是不是某个集成单元的最新版本破坏了系统整体的集成;
  • 持续交付关注的不是集成单元最新版本之间的集成问题,而是关注的是当前集成单元与产品环境上的其他服务的版本是否兼容。

两者的视角不同,持续集成是向前看,持续交付是向后看

 

3 以新的角度看我们的产品

B产品,只做到持续集成

A产品,半持续交付。分两个微服务,每个微服务单独做ci的时候会同时拉取两个模块进行部署测试,如果没有复杂业务逻辑的干扰,两个微服务的上线互不干扰。但是两个模块的ci不能同时进行,会互相block。所以我认为是半持续交付。

四 安利一种部署方式——ISO

1 网关碰到的部署问题

网关全称:业务安全旁路网关。

网关需要提供流量嗅探功能,考虑到性能的提升和减少丢包,用到了pfring这个工具。而pfring的部署需要用到很多rpm包。

假设我们在centos7.4中进行开发,如果客户服务器上不能连接外网并且版本高于7.4,那么将会碰到很多rpm依赖的问题。

如果我们把整个网关系统打包在一个ISO中,就可以实现在客户物理机上安装一个带有网关的linux系统,从而实现真正的一键部署。并且作为ToB产品这种部署方式是很可行的

目前网关不仅完成了ISO打包与部署,还在每天进行着daily buid,每次build都会升级版本build号。这种做法可以对ToB产品的测试与交付中提供很大的帮助。接下来,从网关的部署方式中推荐ToB产品测试与交付的最佳实践

五 ToB产品测试与交付的最佳实践

1 ToB产品交付特征

  • 迭代周期长
  • 对交付的版本的质量要求高
  • 版本升级难度大,步骤繁琐
  • 无法进行灰度发布

2 ToB产品版本发布流程

image.png\

集成测试:

  • 启动ci 做Daily Build
  • build号递增
  • 缺陷跟踪
  • 缺陷发现和修复验证必须制定build号

Alpha测试:

  • 持续进行Daily build
  • 旧版本升级测试
  • 原则上不允许组件升级
  • 回归测试
  • 开发自测
  • 缺陷收敛后准备上Beta环境
  • 记录Beta环境的build号