内建质量定义
内建质量作用在开发过程中，要求软件生命周期之间参与的各个角色都需要实时的对软件的质量负责。确保软件在交付到下一环节前已经有了基础的质量保证。其核心目的就是减少因为质量问题导致的返工，而浪费大量人力成本。
1.敏捷中的内建质量
内建质量是规模化敏捷SAFe的核心价值观，引用下面一段话，我们看一下敏捷中定义的内建质量在讲什么内容（原文出处:https://www.scaledagileframework.com/built-in-quality/）
简单的翻译过来就是，产品一旦被发布之后就有了好坏之分，通过某些检验方式已经无法提高或保证它的质量，所以质量检验必须内置在产品或服务构建的过程中，而不能在它发布之后。
2.DevOps中的内建质量
DevOps三步工作法中，第二步就是反馈原则，其中很重要的一个实践就是在源头保障质量，这里主要是指开发部门、测试部门。而在源头保障质量的通俗说法更像是“谁污染谁治理”。 DevOps倡导所有新的功能特性可以像流动的水一样，迭代到用户的终端，而水是不能逆流的，为了保证水流的质量，我们就必须在水流动的途中治理，直到最终交付到用户的手中。这也就是DevOps建设中一个新的理念“liquid software”
内建质量实践
1. 左移
左移是内建质量最好的实践，把质量问题从源头开始进行检查。
由开发侧发起的单元测试就是最典型的测试左移的案例，虽然高单元测试覆盖率需要投入大量的成本，但是对于某些行业，如金融行业，这个实践是必要的。另外测试左移不止是对代码来讲的，同样在需求评审阶段，就要对需求质量进行评估，推广到市场后是否真的能实现其价值.
随着DevSecOps的兴起，安全左移的重要性也体现出来。我们经历过很多次类似的情况，每当我们把经过了开发测试的软件发布到生产线上，经常会被安全部门或者第三方监管单位找麻烦，归根结底还是因为在开发过程中引入了某些不安全的开源组件,写了有风险的代码，而这些问题可能都是开发人员技术能力之外的。试想一下，如果在开发人员的IDE中直接提示开发代码的安全问题，引用组件的安全问题，并引导开发人员去解决的话，是不是相当于在开发的源头解决了安全问题呢，不但提高了软件的整体安全质量，同样也节省了效能。
2. 门禁
为了贯彻内建质量是否在开发体系中落实，我们需要设置一些质量度量标准，所以在软件生命周期的每个阶段设置质量门禁这种实践孕育而生，在代码提交或集成时，校验单元测试的覆盖率和通过率，检验代码的合规性，验证引用的组件安全性都是质量门禁的实践。如果没有通过质量门禁，说明内建质量没有达到标准，上线后由于质量问题返工的可能性会增加。下述门禁是需要被关注的：
代码质量
单元测试覆盖率
单元测试通过率
测试通过率
基础设施
代码安全性
第三方组件安全性
开源协议扫描
等…
内建质量落地
很多DevOps的建设场景中，最终落地的依旧是工具链，工具链是打通从开发到运维基础。为了保障内建质量的建立，两个方面的工具链是不可缺少的，下面罗列了一些常用的工具，如果大家准备在软件生命周期中增加内建质量的建设，可以参考下述工具
1. 专项工具类，解决特定质量检查场景：
源码质量：SonarQube、checkmarx、fortify
单元测试：Junit
自动化测试：selenium、postman、yapi
性能测试：jmeter
安全：Xray、Dependance-check
2. 集成工具类，打通工具链流程，统一展示：
集成工具：Jenkins、TFS、GitlabCI、tekton、
制品管理工具：Artifactory
总结
内建质量是精益、敏捷以及DevOps的核心原则之一，有助于避免与需求召回、返工及缺陷修复有关的延迟成本。所以内建质量，势在必行。
更多精彩内容可以专注我们的在线课堂
微信搜索公众号：jfrogchina 获取课程通知
