评估与监控CI/CD流水线
“不积跬步，无以至千里；不积小流，无以成江海”，只有不断积累经验、持之以恒改进，才能完成理想的目标。在DevOps中，该过程被统称为持续改进（Continuous Improvement）。作为DevOps的基石之一，持续改进涵盖了DevOps全流程，通过收集和分析构建内容或工作方式的反馈来改进开发过程，从而帮助开发人员确定需要改进的具体阶段并根据需要继续调整。
CI（Continuous Integration，持续集成）/CD（Continuous Delivery，持续交付/Continuous Deployment，持续部署）流水线在实现软件的持续改进方面发挥着核心作用。CI/CD流水线可以帮助开发团队缩短软件发布周期，使发布更为频繁，并收集更多用户反馈。在更轻松地识别软件Bug的同时，开发团队还能根据从中获取的信息调整后续工作的优先级，优化构建、测试和发布软件的过程，从而保证软件的质量。
前序文章已经对“什么是CI/CD流水线”及“如何构建CI/CD流水线”做了详细说明，本文将围绕CI/CD流水线相关评估指标展开探讨。
1.CI / CD流水线评估指标
DevOps研究和评估团队（DevOps Research and Assessment，以下简称DORA）制定了以下4个评估指标，这些指标可准确表明CI/CD流水线在软件开发环境中的表现。
1、交付时间：交付时间指从首次提出功能到功能发布的时间，在这个过程中，设计构思、用户研究和原型制作所涉及的时间往往是高度可变的。DORA采用的方法是测量代码提交到部署的时间，从而使得开发人员可以只关注CI/CD流水线范围内的阶段。较长的交付周期意味着开发人员不会经常对前端代码进行更改，那将无法从用户反馈中受益以改进正在构建的内容，从而影响CI/CD流水线的有效性，此时，可通过构建持续时间指标来确定CI/CD流水线中耗时最久的阶段。
2、部署频率：部署频率指单位时间内使用CI/CD流水线有效部署代码到生产的次数。高部署频率意味着每次部署的更改都属于少量、小幅度的更改，可以降低发布风险（减少可能产生意外结果的变量），并更快地获取反馈。而低部署频率则意味着CI/CD流水线未能定期提供有效代码——可能存在任务未被分解情况。
因业务需要进行批量更改也会导致部署频率降低。在此类情况下，可以通过测量部署到暂存点的频率来监控部署频率。
3、更改失败率：更改失败率指部署到生产中的导致Bug的更改比例。较低的更改失败率能让开发人员对CI/CD流水线充满信心。
4、平均恢复时间：平均恢复时间（Mean Time To Recovery or Resolution，以下简称MTTR）指解决Bug所需的时间。开发人员需要在主动监控系统的同时，利用CI/CD流水线进行快速回滚、更改或部署修复程序，从而使MTTR保持在较低水平。
2.CI / CD流水线的执行评估指标
在实际应用时，开发人员还通过下列指标更好地了解CI/CD流水线的执行情况，并确定需要改进流程的部分。
1、代码覆盖率：代码覆盖率是一种通过计算测试过程中被执行的源代码占全部源代码的比例，进而间接度量软件质量的方法。监控代码覆盖率能够确保CI/CD流水线具备足够的测试覆盖率，也能使测试人员更专注于探索性测试和构建新的测试用例。
2、构建持续时间：构建持续时间衡量了完成CI/CD流水线各个阶段所花费的时间。查看持续构建时间可以发现一些CI/CD流水线的痛点或瓶颈。
3、测试通过率：测试通过率指给定构建成功通过的测试用例的百分比，该指标用以了解代码更改导致测试失败的频率。
4、修复时间：修复时间指解决测试失败问题所需的重构时间，用以指示开发人员响应问题的速度。
5、失败部署计数：失败的部署会导致意外停机，需要回滚部署或紧急运行修复程序。失败部署的计数可用于计算更改失败率。
6、缺陷计数：缺陷计数指被归类为Bug的未处理工单数量，可按测试/暂存中发现的问题和生产中发现的问题进一步细分。
7、部署规模：部署规模影响着部署的复杂性及部署所需时间。小型部署需要的资源较少，且相对容易部署；中型、大型部署则需要更多的时间和资源。
3.评估与监控CI/CD流水线的测试工
通过对上述指标进行评估与监控，开发人员可以更好地掌握CI/CD流水线的运行状态及改进点，从而保证CI/CD流水线时刻处于高效可靠的状态。
SkyEye天目全数字实时仿真软件，是基于可视化建模的硬件行为级仿真平台，在嵌入式软件开发过程中可替代真实硬件完成目标程序的调试和测试，是评估与监控CI/CD流水线的最佳拍档。
SkyEye可解决硬件测试环境搭建成本高、测试环境资源调度困难等问题，让测试更早参与到项目流程中，还可通过容器化部署的形式封装到协作开发环境，助力DevOps实践。