【Kubernetes】CICD分析

Kubernetes CICD总体架构图

DevOps工具集

• 编码：代码开发和审阅，版本控制工具、代码合并工具

Source：Gitlab、Gerrit（未实现）

• 构建：持续集成工具、构建状态统计工具

Build：Jekins、ant、docker

• 测试：通过测试和结果确定绩效的工具

Test：Jmeter、Swagger/OpenAPI、MeterSphere、Postman

• 打包：成品仓库、应用程序部署前暂存

Harbor

• 发布：变更管理、发布审批、发布自动化
• 配置：基础架构配置和部署，基础架构即代码工具

•   Ansible、Puppet

• 监控：应用程序性能监视、最终用户体验

•   efk、Prometheus

注意：

1. 这个环境跟待测试Kubernetes环境独立开来
2. 自动测试流程有两个需求：1）代码修改时 2）临时/周期行验证K8S环境是否正常
3. 分为开发环境、测试环境、类生产环境和生产环境。

云平台CICD环境：

基础概念

CI/CD

 CI(Continuous integration，中文意思是持续集成)是一种软件开发时间。持续集成强调开发人员提交了新代码之后，立刻进行构建、（单元）测试。根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。借用网络图片对CI加以理解。

CI示意图 持续集成示意图

要求

• 团队需要为每个新功能、代码改进、或者问题修复创建自动化测试用例。
• 你需要一个持续集成服务器，它可以监控代码提交情况，对每个新的提交进行自动化测试。
• 研发团队需要尽可能快的提交代码，至少每天一次提交。

优点

• 通过自动化测试可以提早拿到回归测试的结果，避免将一些问题提交到交付生产中。
• 发布编译将会更加容易，因为合并之初已经将所有问题都规避了。
• 减少工作问题切换，研发可以很快获得构建失败的消息，在开始下一个任务之前就可以很快解决。
• 测试成本大幅降低，你的CI服务器可以在几秒钟之内运行上百条测试。
• 你的QA团队花费在测试上面的时间会大幅缩短，将会更加侧重于质量文化的提升上面。

CD(Continuous Delivery， 中文意思持续交付)是在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境(类生产环境)中。比如，我们完成单元测试后，可以把代码部署到连接数据库的Staging（类生产）环境中更多的测试。如果代码没有问题，可以继续手动部署到生产环境。下图反应的是CI/CD 的大概工作模式。

CD示意图 持续交付示意图

要求

• 你需要有强大的持续集成组件和足够多的测试项可以满足你代码的需求。