Docker技术的兴起,推动了很多技术的革新与发展.有我们熟知的微服务架构、DevOps(微服务的好基友)另外一个就是持续集成与持续交付的流程衍变.
对于持续集成的定义有很多种, 这里把它总结为:指开发人员将代码定期合入到中央仓库后触发的一系列构建、静态代码检查、 单元测试、 部署、接口测试等一系列构建或集成的行为。 主要目标是更快发现并解决缺陷,提高软件质量,并减少验证和发布新软件更新所需的时间
首先我们在事先搭建好的持续集成环境中配置好一系列的测试Jobs即pipeline;并且配置好测试的触发条件
具体的测试任务内容会由于产品的形态和发展阶段进行定制, 举一个当前在使用的pipeline的内容: 静态代码检查->单元测试->测试环境部署->结果反馈和展示
当开发小明提交了一次代码的时候, JenkinsMaster检测到代码的变更触发了测试
部署环境的成本较高 (包含持续集成本身) 以持续集成环境搭建为例 ,已上面流程图中的持续集成环境搭建为例子, 我们可以看到搭建一套持续集成环境的必经步骤
测试环境的不一致性相信我们遇到过同一个问题在测试同学发现并反馈到开发同学这里,很难复现.甚至需要开发和测试一起去定位排查问题,最终花费了很多时间结果是由于环境问题导致的.
相对开发周期较长最终的直接影响就是导致开发周期变长
容器和微服务的发展, 让我们经常被问到微服务的测试要怎么做, 怎么样结合docker去做测试甚至是持续集成? 下面就跟大家分享下其中的一个实践:
可以看到这个图与上面的图有哪些比较大的变化?
另外我们创建了一个支持持续集成功能的仓库
最后持续集成执行的测试结果不仅是一个result, 还有一个镜像形式的交付,这个镜像实际上是源码和环境的捆绑内容
再来看一下这个流程:
这里以网易云基础服务提供的容器云为例直观的去理解
怎样通过Jenkinsfile来实现持续集成测试的编排呢
1. 优点
容器化的实践不仅在资源上节省了开销,并且由于容器本身的优势为部署上也带来了便捷. 同时结合了网易云基础平台的持续集成镜像仓库及API等服务, 让容器化的交付成为了可能.一方面解决了部分由环境一致性带来的问题,同时也为持续集成的编排增加了更多的灵活性. 总结了一下主要有已下几点:
2. 问题分析
持续集成在本次实践的过程中,我们借助了网易云的平台,并且同时引进了Jenkinsfile的pipeline编排方法.这对于传统的用户来说,迁移过程中需要有一定的时间去消化并解决实践过程中的种种问题,甚至在微服务化的过程中同时考虑微服务测试的难易程度做适当的调整;另外持续集成和持续交付在容器化的进程中还未达成一个明确的交付标准.这些都需要更多的开发者和测试同学去实践,从而积累更多的经验去总结得出.
本文来自网易实践者社区,经作者张雨授权发布。