19 | 持续交付中流水线构建完成后就大功告成了吗？别忘了质量保障
赵成
该思维导图由 AI 生成，仅供参考
上期文章我结合自己的实践经验，介绍了持续交付中流水线模式的软件构建，以及在构建过程中的 3 个关键问题。我们可以看出，流水线的软件构建过程相对精简、独立，只做编译和打包两个动作。
但需要明确的是，在持续交付过程中，我们还要做很多与质量保障相关的工作，比如我们前面提到的各类功能测试和非功能测试。
所以，今天我们聊一聊在流水线构建过程中或构建完成之后，在质量保障和稳定性保障方面，我们还需要做哪些事情。
首先，我们回顾一下之前总结的这张流程图：
可以看出，在流水线构建过程中，我们尤其要重视以下 3 个方面的工作内容。
依赖规则限制
主要是对代码依赖的二方包和三方包做一些规则限制。比如，严格限定不允许依赖 Snapshot 版本；不允许引入有严重漏洞的版本，如 Struts2 的部分版本；检测 JAR 包冲突，如我们常用的 Netty、Spring 相关的包；限定某些软件包的最低版本发布，如内部提供的二方包，以确保版本收敛，降低维护成本。
过滤规则上，通过 Maven 构建软件包过程中生成的 dependency:list 文件，将 GroupID 和 ArtifactID 作为关键字，与我们设定的版本限制规则进行匹配。
两个示例如下（真实版本信息做了修改）：
检测 JAR 包冲突：
[WARNING] 检测到 jar 包冲突: io.netty:netty-all, 版本: 4.0.88.Final, 当前使用:
4.0.22.Final
限定最低版本：
[WARNING] 检测到 mysql:mysql-connector-java, 版本 5.0.22, 版本不符合要求, 需要大于等于
5.0.88。旧版存在已知兼容性 bug，导致连不上数据库, 请在 2018-01-15 00:00:00 前升级完成, 否则将被禁止发布，如有疑问，请联系 @发布助手
JAR 包依赖以及维护升级，通常是一件令我们比较头疼的事情，特别是在运行时出现的冲突异常，更是灾难性的。为了从技术角度更好地进行管理，我们需要做好隔离，这一点可以利用 JVM 类加载机制来实现。
如果你有兴趣，可以在网上参考阿里的潘多拉（Pandora）容器设计资料，这里我们就不作详细介绍了。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
持续交付中的流水线构建完成后，并不意味着任务已经完成。除了软件构建过程外，质量保障和稳定性保障同样重要。在流水线构建过程中，需要重视依赖规则限制、功能测试和非功能测试。依赖规则限制包括对代码依赖的规则限制，如禁止依赖Snapshot版本、限定最低版本发布等，以确保版本收敛和降低维护成本。功能测试包括单元测试、接口测试、联调测试和集成测试，其中单元测试和接口测试可以通过自动化手段完成，确保代码质量和覆盖率。非功能测试则包括安全审计、性能测试和容量评估，用于识别漏洞和验证性能。这些验证工作需要在预发或Beta环境下进行，以确保软件包发布前后的性能和容量没有较大差异。整个持续交付体系需要基于各类环境和基础配置管理进行验收，涉及软件的部署发布。下一期文章将分享线上发布的整个过程，并对整个持续交付体系内容做一个收尾。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《赵成的运维体系管理课》，新⼈⾸单¥59
《赵成的运维体系管理课》，新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(1)
- 最新
- 精选
符亮请问大佬这个cobra跟sonarqube有什么差异？为什么使用sonarqube呢？2020-07-2222
收起评论
