Pipeline - iT 邦幫忙 | Pipeline
Pipeline[1]是一個自動化的管線運輸貨物方式。從撰寫程式開始到程式上線,中間經過的流程通常都會是固定的,因此我們或許也可以把程式看成是貨物,使用Pipeline的概念將各階段的自動化處理整合起來。程式的修改只要有觸發,都可以啟動自動化處理,讓修改的過程成為一個「程式流」。這個主題跟昨天的BuildScript[2]互有關係。昨天先定義好各階段的自動化,今天是在定義「前一階段的結果送交給下一階段開始處理」的自動化,有點類似Kanban的「從Done到Doing」的自動化。以下繼續由昨天的例子延伸來討論:Development開發階段可以做的觸...
Pipeline[1] 是一個自動化的管線運輸貨物方式。從撰寫程式開始到程式上線,中間經過的流程通常都會是固定的,因此我們或許也可以把程式看成是貨物,使用 Pipeline 的概念將各階段的自動化處理整合起來。程式的修改只要有觸發,都可以啟動自動化處理,讓修改的過程成為一個「程式流」。
這個主題跟昨天的 Build Script[2] 互有關係。昨天先定義好各階段的自動化,今天是在定義「前一階段的結果送交給下一階段開始處理」的自動化,有點類似 Kanban 的「從 Done 到 Doing 」的自動化。
以下繼續由昨天的例子延伸來討論:
Development開發階段可以做的觸發與自動化非常多樣化,比方前端最常使用的 gulp watch ,或是 watch 配合 codeception ,當有修改就做單元測試;而在提交版控前,可以掛上 hook ,讓提交程式之前,會做一些必要的測試和基本的檢查,比方說較快的整合測試和 Coding Style 檢查。這些都是可以由開發者人員由搭配使用的,也因此套件管理系統通常也會定義一個區塊的套件是開發用,另一個是上線用,為的就是讓開發人員方便開發。
但不管怎麼調整,開發人員的任務是寫出「可用的程式碼」,而可用的定義是指上述測試通過。當然也是可以定義人工 UI 測試成功即表示程式是可用的,但測試範圍(即成本)跟品質是有直接相關的,這是管理人員該考慮是否要投入成本。
Testing理論上當開發人員提交程式的時候就可以開測了,只是看要完整的含人工測試,還是自動化測試跑一跑就好。通常版控系統都會有收到 push 的 hook 可以掛到 CI server 上,而 CI server 收到開發人員完成程式的通知時,會去抓最新的程式碼並做自動化測試與產生報表等。
自動化測試執行完畢後,錯誤的話, CI Server 會記錄並通知開發人員。正確的話可以看下一步流程。如果有執行 code review 的話,開發人員可以在覺得可行的時候手動發 PR 給 reviewer 。當 reviewer 覺得沒問題,可以佈署預發佈環境時,就能...