通過靜態分析和持續整合 保證代碼的品質 （PRQA ）2

標籤：

續上。。。。

第二章 部署樣本：Jenkins and PRQA 工具

第一節 Jenkins 作為持續整合系統

現在有很多持續整合工具，既有免費的，也有商業的。最近的研究顯示，Jenkins正發展成為最受歡迎的持續整合工具。Jenkins是Hudson持續整合系統的一個分支，但是Jenkins擁有最活躍的生態系統。

在MIT許可下，Jenkins是免費的，但是和一些開源軟體一樣，Jenkins也有付費版本，並會提供支援人員。雖然Jenkins是一個開源項目，但是對核心代碼所作的所有修改，都由核心提交者嚴格把控，其中一位核心提交者就是項目架構師Koshuke Kawaguchi。

系統概述

Jenkins是用Java寫的，由一個很小的核心和一個內建網站伺服器組成。大多數使用者與Jenkins的互動都是通過常規網頁瀏覽器來實現的，不需要安裝特別的用戶端軟體。

靈活性是優質持續整合系統的一個主要特性，它能夠滿足所有公司的業務要求。Jenkins有兩個非常重要的結構特點，使得它既可自訂又可擴充：主/從分布式構建結構和外掛程式。

主/從結構

雖然Jenkins經常以主/從安裝形式配置，但其實Jenkins也可以部署在一台獨立的電腦上。由一個主機控制何時進行代碼的構建和測試，並為使用者提供介面。Jenkins上的所有任務都叫做事件。由一個或多個從屬機器執行實際的構建和測試工作。構建（工件，如最終的二進位檔案、程式包、測試報告，等等）產生的所有重要結果，都會從從屬機器轉移到並儲存到主機上。中間檔案，如目標代碼，還是保留在從屬機器上（會定期移除）。主機會保留所有的曆史構建結果，因而可以判斷出項目的趨勢。

從屬機器沒有什麼特別的 —— 只要是裝有所需的開發與測試工具的現成電腦就可以了。從屬機器可以運行與主機不同的作業系統——這對於為多平台編寫代碼有重要意義。從屬機器也可以串連到硬體裝置，以便可以將嵌入式代碼下載到實際裝置中進行測試。從屬機器也不一定要是實際機器，現在虛擬機器正在越來越廣泛地被用做從屬機器，採用雲端式的解決方案，因為這種方法成本較低。

外掛程式

Jenkins完成的大多數自訂任務都是通過外掛程式來實現的。Jenkins核心中定義好的應用程式介面（API），可以通過安裝外掛程式來豐富圖形化使用者介面（GUI）的配置選項，這些功能在使用的時候就好像是核心的一部分一樣。

現在有超過800（正在增多）種外掛程式，外掛程式涉及很多方面，包括：版本控制系統的互動作用、代碼構建、測試、報告、工件管理。通過安裝相關的外掛程式，可以定製Jenkins，以適應項目的構建和測試需求。

儀錶盤

Jenkins可通過儀錶盤模式顯示所有事件的整體狀態。每個事件的狀態都以點狀形式顯示，顏色表示上次執行的狀態（在預設情況下，紅色表示失敗，黃色表示不穩定，藍色表示成功——但是和Jenkins中的大多數功能一樣，顏色也是可以自訂的）。閃爍的點表示該事件正在構建中。用“天氣”的標誌，通過晴天（太陽）、陰天（雷雲）等天氣狀態，以比較直觀的形式總結出最近的構建情況。

儀錶盤會顯示事件隊列 —— 待構建事件的列表。同時還會顯示從屬機器的狀態，指出哪些事件是不啟動並執行，哪些正在執行。圖4顯示的是Apache Software Foundation的Jenkins儀錶盤。

圖4 Jenkins儀錶盤

圖4顯示的是Jenkins儀錶盤。右側顯示的是事件列表。左下方顯示的是從屬機器列表，從屬機器列表的上方顯示的是構建隊列。

事件

每個事件都有一個頁面記錄構建的曆史情況，通常情況下，是一些圖形化輸出，顯示測試狀態以及與最近的構建工件、代碼修改及其它重要或相關的資料。

一個事件可被拆分成3個頂級階段：

1. 構建前。在這個階段，會從存放庫中檢出最新的代碼。通常是先檢查存放庫，看是否有新代碼提交進來，如果有就檢出。也可能是根據時間安排或在完成了其它事件之後，對存放庫中的代碼進行檢出。
2. 構建中。這一步在大多數實際工作完成之後開始，包括：從編譯和耦合到對代碼進行測試。Jenkins會記錄所有命令的控制台輸出，以便排除故障。
3. 構建後。在這一過程中，需要對構建好的代碼進行進一步測試。同時還要收集並解析測試結果，最後將結果顯示出來。並將所需的工件存檔到主機上。

構建階段和構建後的階段需不需要包含多個步驟，取決於構建/測試的需求，以及所安裝的外掛程式。

一個簡單的事件可能要進行以下配置：

1. 構建前: 版本控制系統應用程式，存放庫的路徑，模組名稱
2. 構建中：包含簡單的“make”命令的shell執行步驟
3. 構建後：對工件進行存檔時要使用構建階段產生的可執行檔的名稱。

在執行事件的時候，Jenkins會從存放庫中檢出最新版本的代碼，然後在shell中執行“make”命令，並將產生的可執行檔複製到主機上。如果其中某一步執行失敗了，那麼後面的步驟就都無法執行了，所以事件的狀態就會顯示為“失敗”。只有當所有的步驟能準確無誤地執行完成之後，該事件的狀態才可能顯示為“成功”。如果能達到這個最基本的水平，就可以用Jenkins安排夜間構建。

入門指導 

Jenkins的入門很簡單 —— 它可以以一個完整、可啟動並執行網路應用程式的封存檔案形式存在。該檔案可以下載並執行 —— 但是，為了正確安裝，要將它以服務/背景程式的形式安裝，並按許可權以使用者的身份執行。

 

第二部分：利用PRQA Jenkins外掛程式進行靜態分析

PRQA的Jenkins外掛程式，可與我們的靜態分析工具QA·C 或QA·C++一起使用，來對原始碼進行分析。在構建完成之後的階段，該外掛程式自動執行以下主要任務：

1. 分析項目
2. 產生合規報告
3. 將項目中的資訊總數與可配置的臨界值進行對比，如果超過了該臨界值，就將構建狀態設定為“不穩定”：可以將其當作大門，阻止後續任務的執行。
4. 有選擇性地將分析結果上傳到QA·Verify中，這是PRQA的網路品質管理系統。

分析階段的工作可以通過“依賴模式”來開展——所以只需要對在上次分析之後有所改變的檔案進行分析，從而盡量減少項目的分析時間。也可以在構建階段進行分析（比如Makefile整合），並向外掛程式提供列表，列出所有經過分析的檔案，讓外掛程式可以識別到已分析過的檔案。

5，外掛程式將概要資訊顯示在事件網頁上。

圖5 使用PRQA外掛程式的事件（為適應頁面大小改變了一下格式）

遵從度和每次構建時產生的資訊總數都能以曲線圖形式顯示出來，這樣就很容易看到編碼規範的違規趨勢。合規匯總表顯示項目和檔案的合規百分比（這些資料可從QA·C/QA·C++合規報告中擷取，報告會詳細指出不符合編碼規範的代碼）以及所產生的資訊總數。第二個表顯示的是各個層級的分解資訊。外掛程式會自動封存所有報告，所以在項目合規狀態方面能夠提供更詳細的資訊。

違規數量的臨界值可設定為絕對值，比如0，表示不允許有任何違規行為。此外，還可以設定執行臨界值的資訊級，這樣就可以將資訊的嚴重性等級考慮在內。如果代碼需要的維護工作不是特別複雜，樣式方面的問題也不是很嚴重，就可以視為通過；但是如果代碼有嚴重的問題，就不能通過。

能夠將分析結果上傳到QA·Verify是該外掛程式最強大的功能。將結果上傳之後，開發人員就可以看到深入的分析結果，包括帶註解的原始碼，這些結果中會顯示違反編碼規範的具體位置。該外掛程式還允許添加、管理和報告違反編碼規範的代碼，並可自動校對代碼是否遵循編碼規範，如MISRA C。QA·Verify也會向其它項目相關者（比如，管理員，甚至是客戶）公開這些品質資訊。圖6展示了PRQA工具是如何與Jenkins配合使用的。

圖6：Jenkins與QA·C，QA·C++，QA·Verify配合使用的情況

開發人員像平常一樣提交代碼（代碼先提交到臨時庫中，當代碼通過所有測試時，再轉入正式庫）。要配置持續整合伺服器，以便可以對原代碼進行 QA·C 或 QA·C++分析。概要資訊，如：通過整合服務器可以瞭解代碼是否遵循了最佳編碼慣例，而且，分析結果還可以自動上傳到QA·Verify。這樣開發人員就可以通過網頁瀏覽器看到帶注釋的原始碼，從而準確找到不符合編碼規範的地方，以便在重新提交代碼之前修複這些問題。

其它項目相關人員可以在QA·Verify中看到帶注釋的原始碼，但是管理層和質檢人員等，會希望瞭解更多其它更進階別的資料。管理層可能不太想看原始碼，他們感興趣的應該是：代碼中有多少問題——問題的數量是呈上升還是下降趨勢。因為可以看到項目中不同層級的資訊，管理層在做決定時，就可以根據必要的資料來判斷應該如何重新分配資源。

 

結論

通過持續整合，很容易就能夠“循序漸進地”將最佳編碼慣例應用於靜態分析中。持續整合能夠讓整合和測試環節貫穿整個開發階段，這將為開發帶來很多裨益。因為這樣有利於在問題變得嚴重之前儘早解決，還能保證存放庫中的代碼一直處於高品質狀態。

使用外掛程式，很容易能夠將PRQA靜態分析工具QA·C和QA·C++與Jenkins持續整合結合起來，從而迅速給出反饋，指出代碼是否遵循了編碼規範和最佳慣例。該外掛程式還能夠將結果上傳到QA·Verify，以便進行深入的調查研究和趨勢分析。

將持續接觸和PRQA的靜態分析工具結合起來能夠協助提高代碼的交付品質，並且能保證在規定時間和預算範圍內實現交付。

通過靜態分析和持續整合 保證代碼的品質 （PRQA ）2