企業做DevOps平臺，本質上是做企業的IT生產線，最終是實現整個企業級的數字化生產線。構建作為落地DevOps平臺必不可少的環節之一，是持續集成、交付和部署的基礎。本文我們從DevOps的CICD總體思路出發，和大家分享一下DevOps是如何做構建管理的。
目錄：
一、CI/CD總體思路
二、構建定義與任務編排
三、構建策略
四、構建執行與跟蹤
五、總結
一、CI/CD總體思路
在DevOps中，做到持續構建是基本的，其中複雜的地方主要是對多種環境的構建支撐。項目中有用maven編譯的、有用ant編譯的，如果有移動應用，有android系統的、ios系統的，還有一些前端應用的編譯，比如：nodejs，這麼多不同的環境我們怎麼支持？另外，構建過程中還需要考慮和代碼質量分析，單元測試、介質上傳等能力的結合，這樣的構建過程其實也是一個工作流程。
舉個最典型的例子，比如：構建時，先要進行maven編譯，編譯過程中包含單元測試，然後進行代碼質量分析，之後將交付物上傳到二方庫，最後還要看到構建詳情、日誌、單元測試報告、代碼質量分析報告等詳細情況，可以查看並下載介質。只有完成了這樣一個過程才能說基本做到了持續集成。
我們的DevOps中持續集成與持續部署的總體設計思路就是在DevOps中進行設計，然後通過Jenkins執行的方式。DevOps負責進行構建定義或部署架構的設計，生成Jenkins的pipeline job的配置文件；然後Jenkins根據這個配置文件創建並執行pipeline job；DevOps再通過Jenkins的Rest API跟蹤執行進度和結果。
之所以用Jenkins，正是因為它強大的集成能力和基於groovy腳本的可擴展工作流設計。Jenkins實現了與眾多插件的集成，可以通過groovy命令調用git、maven、npm、gradle、shell、junit、sonarqube、ansible、docker、openshift、kubernetes等插件，讓我們的集成工作非常簡便。其次，Jenkins的核心Pipeline的實現方式就是使用Groovy腳本來表述複雜的流程，既可以支持點狀的持續集成也可以支持線狀的持續部署，能夠支持複雜的構建和發佈流程。關於Pipleline的介紹大家可觀看我們的短視頻：Jenkins集成（http://p.primeton.com/articles/599e770e4be8e65e9c008522）。
此外，順便分享一下我們集成Jenkis時遇到的一些難點。
首先是執行效率問題，我們的DevOps通過API啟動Jenkins時，Jenkins先排隊調度再執行的機制造成啟動較慢，比如會等待5，6秒，有時甚至是10幾秒的情況，之後才會開始執行真正的腳本，用戶體驗較差。這方面我們自己通過異步和隊列來解決用戶體驗問題。
其次是信息去重問題，Jenkins的Master-Slave的集群模式，使得我們在從多節點獲取執行情況時需要進行去重處理，目前我們採用輪詢加鎖的方式解決。
此外是信息擴展問題，從Jenkins獲取的結果都是日誌形式的，Jenkins沒有很好的擴展機制來支持定製，比如：過濾用戶名密碼、獲取URL地址等等，需要DevOps自己進行過濾和處理。（如：有些需要的信息只能通過腳本先寫到日誌中再獲取；用戶名和密碼明文存放，需要進行過濾和處理等等）。
另外，Jenkins的官方客戶端REST API文檔不太健全，需要通過調試的方式自己摸索。
二、構建定義與任務編排
首先我們瞭解一下DevOps的構建定義。這是DevOps中持續集成的操作流程。首先，可以在項目中創建構建定義，在每個構建定義上可以選擇若干個需要的構建任務，通過原子步驟進行編排，組裝成一個完整構建流程。通過觸發策略和保留規則的定義，可以在代碼提交時觸發構建（支持gitlab、github、svn等常用代碼庫版本管理工具），或者在指定時間進行日構建。在最新版本的DevOps中，我們增加了組件的構建定義，一個構建定義可以對應一個或多個組件。
在構建定義時，DevOps中的每個構建任務對應jenkins的一個pipeline stage。在執行時，將所有構建任務結合構建定義的一些基礎信息，創建jenkins的pipeline job進行執行。
目前DevOps平臺將構建任務分成了三類：第一類是構建類任務，如：從Git/SVN拉代碼、使用Maven、Ant、Npm、Gradle進行編譯，以及調用已有的構建定義進行構建等與構建相關的；第二類是測試類任務，如：執行Sonarqube代碼分析、Jmeter測試、Selenium測試等與測試和代碼分析相關；第三類是
工具類任務，如：Shell腳本執行、介質提交到Nexus倉庫、介質上傳二方庫等。
DevOps通過原子任務+任務編排的方式來支持複雜的構建場景。那麼，我們為什麼要做編排呢？從構建任務的分類上大家可以看到，項目中使用的編程語言五花八門，對應的編譯工具也各有不同，代碼分析和測試工具也是五花八門，面對不同語言、不同類型的工具在構建過程中可能出現各種情況的組合，如何能夠靈活地支撐這種任務的組合呢？最靈活的方式就是能夠讓開發人員自己根據需要進行編排。
DevOps首先將構建任務原子化，抽取成各種類別的原子任務，然後通過編排的方式將這些原子任務進行串接，就形成了靈活的任務組合，通過這種靈活的編排就可以支持各種類型應用的持續集成。之前看到的三大類構建任務就是目前我們DevOps已經抽取的原子任務，我們還在不斷擴展原子任務，以支持更多的構建使用場景。
下面是DevOps對幾類常見應用的持續集成的支撐。
對於springboot類的應用，首先是拉取代碼，可以從Git庫拉取，也可以從svn拉取，接著是構建，可以使用maven構建，也可以使用ant，gradle構建，然後用SonarQube進行代碼分析，最後執行一些腳本並提交介質。
對於移動類的應用，目前我們支持安卓應用的構建，首先是拉取代碼，可以從Git庫拉取，也可以從svn拉取，接著使用gradle構建，然後進行測試，最後是提交介質。對於ios應用的編譯涉及到證書管理，我們正在擴展相關的構建任務。
對於前端應用，步驟類似，可以選擇npm進行編譯。
總之，通過不斷擴展原子構建任務，並通過編排的方式定義構建流程，我們就能夠支持更多的構建使用場景。
順便提一句，按照我們DevOps的擴展機制擴展構建任務是不需要進行前端代碼開發的，可以自動生成配置界面，是不是很酷？
三、構建策略
超時策略
我們在DevOps中進行構建定義時，可以配置超時時間。這個超時時間是指在Jenkins中執行這個構建流程的時候，最長允許執行多長時間，如果超過這個時間，這個構建流程就會被Jenkins強行終止。
為什麼要定這個超時策略，定好的構建流程為什麼要強制終止呢？
這裡面主要有兩個原因：
-
一是在微服務架構下，構建任務非常頻繁，我們認為每一次構建都應該高效完成，不能超過一定的時間，如果超過這個時間，排除外部因素，可能就是這個微服務的設計或者實現有問題，或者測試用例寫的有問題，不停調用外部資源，導致執行得很慢。
二是碰到一些外部因素，比如網絡不太穩定的情況，導致某一個構建環節時間過長，比如從github拉代碼或者將構建產物上傳到Nexus倉庫，網路傳輸很慢，這樣會因為這個編譯任務被掛起，而導致所有後續的編譯任務都在排隊，整個jenkins Job無法正常執行，同時還佔用了系統資源。配置超時後，可以及時釋放佔用的資源，提升整體構建效率。目前我們DevOps中默認的是10分鐘，如果超過這個時間構建就會自動終止，並自動提一個Bug。開發或管理人員可以跟蹤日誌定位構建超時的具體原因，優化內部實現或調整外部環境。
保留策略
保留策略可以定義我們需要保留幾次構建記錄，成功的保留幾次，失敗的保留幾次。設置了保留策略之後，DevOps會保留最近幾次的構建記錄，而將之前的構建記錄，主要包括Jenkins上的日誌和臨時空間清理掉。設置這個保留策略，主要是為了節省存儲空間，因為每次構建都會生成一些構建日誌和臨時空間裡的文件，通過保留策略可以優化Jenkins的磁盤空間使用效率。我們可以在構建歷史中看到保留下來的那些構建記錄。
-
觸發策略
觸發策略是指這個構建流程在什麼時間會被執行。DevOps支持代碼提交時觸發構建、定時構建、手動構建三種構建觸發策略。
第一種代碼提交時觸發構建，支持通過gitlab或github管理的代碼庫。DevOps平臺提供了觸發構建的RestAPI，只需要在github或gitlab的webhook中配置payloadUrl，調用DevOps提供的RestAPI即可。可以根據需要擴展RestAPI實現，配置在其它時機觸發，比如打Tag的時候，添加註釋的時候等等。第二種是定時構建，就是每天到指定的時間就開始執行構建任務。DevOps提供了定時器，可以按照給定的時間定時觸發執行日構建，這也是最常用的一種方式。第三種是手動構建，可以根據需要隨時手動執行構建。總之，觸發策略的目的就是讓我們能夠在需要的時間進行構建。
通知策略
當需要將構建結果通知項目組成員時可以配置通知策略，在發佈流水線中也可以配置通知策略。DevOps目前支持發送郵件通知，還可以根據需要擴展短信通知、微信通知等多種通知形式。只需要選擇通知發送的項目組成員即可，設定完畢後DevOps平臺將會發送構建成功或失敗的郵件給選定的成員，以便相關人員及時瞭解構建結果。
四、構建執行與跟蹤
首先介紹一下構建執行。構建執行與觸發策略配置相關，可以在代碼提交時觸發執行，也可以定時觸發每日構建，這兩個是DevOps自動執行，還可以根據需要手動執行。
無論是自動觸發執行構建還是手動執行構建，DevOps的構建執行流程都是一樣的。首先是DevOps根據構建定義生成Jenkins pipeline job配置文件，並調用Jenkins API傳遞配置參數啟動Jenkins pipeline job，然後，Jenkins根據配置參數創建Jenkins pipeline job，執行pipeline job，通過Groovy腳本驅動相關的插件執行任務，最後，DevOps調用Jenkins Rest API查詢執行進度和結果，這就是構建執行的大致流程。在執行過程中，開發人員還可以實時跟蹤構建的執行進度，DevOps能夠顯示每一步的執行狀態，是成功了還是失敗了，以及每一步執行的時長。
構建執行結束後，我們可以在DevOps中跟蹤構建執行的情況、查看構建日誌、查看質量報告，下載構建介質，跟蹤構建歷史。
首先，我們可以跟蹤構建執行的總體情況，構建是成功了還是失敗了，構建執行了多長時間，產生了幾個構建產物。點擊每一個任務的鏈接我們還可以查看這個任務的執行日誌，瞭解任務執行的詳情。
如果任務執行失敗了，我們可以通過日誌定位失敗的原因。
此外，在控制檯信息裡DevOps提供了整個構建過程的日誌瀏覽，包括相關的上下文信息，我們也可以通過控制檯信息來定位構建過程中的問題。
其次，我們可以查看代碼質量情況。
有單元測試的，可以看到單元測試通過了多少，失敗了多少，耗時多少。並且可以查看測試明細，瞭解是哪一個單元測試失敗了，耗時比較長。對於Java項目DevOps在Maven構建時集成了Junit進行單元測試，我們在構建定義時如果選擇了執行Junit測試，在單元測試報告中就可以看到Junit的測試報告；對於前端項目可以根據需要在前端代碼編譯時選擇單元測試插件，在DevOps中使用npm構建時配置單元測試報告存放路徑，這樣就可以在DevOps中查看前端項目的單元測試結果了。
如果在構建定義時添加了SonarQube代碼質量檢測任務，我們還可以看到SonarQube的代碼質量分析結果。有多少缺陷，多少漏洞，多少壞味道。點擊鏈接可以進入SonarQube查看更詳細的質量報告。
對於前端項目如果在項目中配置使用了代碼質量掃描插件eslint，在DevOps中使用npm構建時配置eslint報告存放路徑，就可以在DevOps中查看前端項目的Eslint報告，瞭解代碼質量情況。
另外，DevOps還提供了構建介質下載鏈接，可以查看構建後的介質列表並下載介質。
如果我們想了解近期的構建情況，可以通過構建歷史查看DevOps保留的構建記錄。在構建歷史中，我們能夠看到近期執行構建的情況，每次執行了多長時間，是成功了還是失敗了或者是被超時取消了，能看到的構建記錄數與保留策略的設置相關。點擊具體的構建我們就可以瞭解這次構建的詳細情況。
五、總結
總結一下，在DevOps中進行構建，平臺幫您屏蔽了不同操作系統、不同構建工具、不同應用等等複雜的環境，您可以很方便地編排自己的構建流程，定義構建策略，並對構建結果進行跟蹤。構建的目的是幫助我們隨時獲取可運行的產品，是向自動化運維邁進的第一步。
關於作者：李卜，普元DevOps佈道師，曾任普元多個產品的項目經理，並作為資深諮詢顧問參與工行、德邦物流、上海規土等多個項目開發和過程管控。擁有超過15年的開發團隊管理和軟件架構設計經驗，致力於高效研發過程的落地和不斷改進推廣。
閱讀更多 EAWorld 的文章
