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