持續整合樣式：中文補充說明

Jan. 07 20:40~21:45

去年 12 月底 Teddy 介紹了幾個持續整合樣式（Installation Project ，Single Shared Library Project，剩下的 Patterns ），由於這幾個 patterns 是從 Teddy 與指導教授合寫的英文 paper 直接摘錄出來，所以內容也是英文。考量到許多『中文程度特好』的鄉民們可能不想看番邦的文字，為了推廣這些 patterns，Teddy 就用中文以重點說明的方式再介紹一次（路人甲內心獨白：用中文寫還是 不看 看不懂...XD）。

首先看到樣式分類表：

樣式分類	分類說明	樣式名稱
專案 (Project)	軟體專案為了模組化、派工、可維護性、可整合性等需求，將專案切分為不同類型的子專案。此分類中的樣式說明各種不同類型專案的特點與使用時機。	Interface Project, Cross-Platform Project, Native Project, Single Shared Library Project, Installation Project, Patch Project
建構 (Build)	簡而言之，建構是將軟體原始碼轉換為可執行程式的（一連串）動作。此分類包含跨平台專案持續整合所涵蓋的多種不同建構相關樣式。	Local Private Build, Remote Private Build, Cross-Platform Integration, Integration Workflow
使用持續整合的好習慣	不良的軟體開發習慣會大幅降低持續整合的效益，此分類列出使用持續整合的好習慣。	Single Responsible Person

接著是樣式的說明： 

專案分類樣式 

Interface Project：此樣式主張要嚴格區分『介面專案』與『實作專案』，以增加跨平台系統彈性並隱藏平台相依細節。區分應用軟體介面（interface）與實作是一個常見的軟體設計方法，例如微軟的資料庫存取介面 ODBC 以及 Java 的資料庫存取介面 JDBC 都只有提供介面定義，由不同的資料庫廠商提供專屬的實作。從程式設計的層面來看，物件導向程式開發所倡導的 programming to an interface, not an implementation，以及近幾年廣為流行的 dependence injection 樣式 ，也都符合此精神。對跨平台軟體而言，嚴格區分軟體系統的服務介面與實作程式碼，更可達到隱藏平台相依細節，使得程式更具有擴充性與較佳的維護性。

Cross-Platform Project：此樣式說明如何組織與平台獨立的程式。如果一個跨平台軟體的全部程式碼都是與平台相依沒有可共用的部份，則該軟體開發應被視為多個彼此獨立且不相關的專案。跨平台專案可再被細分為與平台獨立以及與平台相依的子專案，以方便程式開發、派工、整合、與測試等。與平台獨立的專案可扮演控制者（controller）的角色，依據軟體所執行的平台動態呼叫與平台相依的軟體元件。從整合與測試的角度來看，與平台獨立的專案較容易使用虛擬環境來執行整合與測試工作。在將程式碼提交到持續整合系統之前，通常只須搭配 Local Private Build 樣式便可確定其程式可以被成功建構。

Native Project：此樣式說明如何組織與平台相依的程式。與平台相依的程式需要為其準備特定的整合環境，在將程式碼提交到持續整合系統之前，通常需要搭配 Remote Private Build 樣式以確定其程式可以被成功建構。

Single Shared Library Project：此樣式說明不同類型的子專案之間如何共享軟體元件或函式庫。此樣式建議將第三方廠商所提供的軟體元件，或是自行開發專案成功建構後所產生的二進制檔案（例如 Windows 上的動態連結函式庫或 Java 的 jar 檔）統一放置到一個二進制函式庫專案中。當不同的專案需要參考到這些元件時，便有一個統一集中處可取得這些檔案，避免不同子專案使用到不同版本的相同元件的問題。當 Installation Project 樣式要產生安裝程式時，也可到此專案中來取得所需的檔案。

Installation Project：此樣式建議為安裝程式單獨建立一個專案，以便簡化製作跨平台專案安裝程式的複雜度。Windows 與 Linux 作業系統的程式安裝模式差異很大。Windows 程式大多採用 GUI 介面，而 Linux 程式則使用文字介面。因此，對跨平台專案而言，應該幫安裝程式單獨建立一個專案用以處理不同平台安裝的問題。

Patch Project：此樣式建議為『補丁』程式單獨建立一個專案，以便製作跨平台軟體更新程式。

建構分類樣式

Local Private Build：此樣式建議開發者將程式碼提交至持續整合系統前，應在本地端自行建構，確定無誤後方可提交。持續整合建構失敗，代表著嚴重的問題，必須受到開發團隊的重視。如果開發者在不確定自己修改的程式是否正確的前提下，就貿然提交程式碼，則很可能經常造成整合失敗（broken build）。由於人們的專注心力有限，大量且過於頻繁的整合失敗事件，最終將導致無人關心而使得持續整合流於形式或荒廢。

Remote Private Build：此樣式是 Local Private Build 的跨平台專案版本。假設某跨平台專案需支援 Windows 與 Linux 作業系統，開發者選定 Windows XP 為其開發平台，也遵守 Local Private Build 樣式，但是因為此 Local Private Build 只在開發者的 Windows XP 平台上被驗證，而沒有在其他（Linux）平台上建構，因此還是可能發生提交程式碼導至整合失敗的事件。因此，若能將 Local Private Build 發布到遠端不同於本地端的平台上建構，則將可降低整合失敗的機率。

Cross-Platform Integration：此樣式建議使用單一持續整合系統來支援跨平台專案建構。由於跨平台專案必須要在不同的平台上執行整合系統活動，因此若採用只支援單一平台的持續整合系統，則我們勢必要在每一個平台上都安裝一套持續整合系統，方可執行整合工作。這將是十分繁雜與耗費時間的工作，而且容易出錯。因此，針對跨平台專案，應挑選支援跨平台專案建構的單一持續整合系統，以簡化持續整合工作。

Integration Workflow：此樣式闡述如何規劃跨平台持續整合流程。持續整合活動可以包含多種不同的建構項目，從最基本的編譯、單元測試、包裝，到較進階的靜態程式碼分析、測試涵蓋率分析等。對跨平台專案而言，每次建構都需要在所有的平台上執行一次建構活動，整個建構流程可能會耗費相當長的時間。過長的建構時間將導致使用者降低執行持續整合的頻率，違反持續整合精神。因此如何規畫整合流程對於跨平台專案更顯重要。

使用持續整合的好習慣樣式

 

Single Responsible Person：此樣式建議專案團隊指定專人接受建構失敗訊息，並由其負責發起後續矯正活動。

***

結論：以上藥方，保證不含防腐劑，搭配 Continuous Integration: Improving Software Quality and Reducing Risk 與 Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation 二書一併服用，效果更佳 。每日三餐三次，連續服用三個月，保證廋10公斤  保證軟體專案開發『豬』事大吉。

***

友藏內心獨白：李加銅說，笨蛋才看 PTT ，聰明人都看搞笑談軟工... XD。