內建質量定義
內建質量作用在開發過程中，要求軟件生命週期之間參與的各個角色都需要實時的對軟件的質量負責。確保軟件在交付到下一環節前已經有了基礎的質量保證。其核心目的就是減少因爲質量問題導致的返工，而浪費大量人力成本。
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 獲取課程通知