iT邦幫忙

2017 iT 邦幫忙鐵人賽
DAY 21
1

Pipeline 是一個自動化的管線運輸貨物方式。從撰寫程式開始到程式上線,中間經過的流程通常都會是固定的,因此我們或許也可以把程式看成是貨物,使用 Pipeline 的概念將各階段的自動化處理整合起來。程式的修改只要有觸發,都可以啟動自動化處理,讓修改的過程成為一個「程式流」。

這個主題跟昨天的 Build Script 互有關係。昨天先定義好各階段的自動化,今天是在定義「前一階段的結果送交給下一階段開始處理」的自動化,有點類似 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 覺得沒問題,可以佈署預發佈環境時,就能按下 Accept 了。

Deployment

按下 Accept 時,可以再接 PR hook 給 CI server ,讓 CI server 知道這次是要玩真的了。 CI server 這時除了上述測試外,也需要產生一包發佈用檔案,並標記這些檔案的版本資訊等。有了發佈用檔案後, CI server 就能進一步佈署到預發佈環境。

這時就能做更多測試,如滲透測試、效能測試、可用性測試、 E2E 測試,等等。等所有測試與檢查都完成後,這一包發佈用的檔案,就是一份可以正式上線的程式了。

Artifacts

注意裡面有些流程會有產生一些非原始碼的檔案,如編譯過的檔案或報表等,這些檔案通常稱為 Artifacts 。它們不需要被版控系統所控制,因為原始碼就能產生一樣檔案,但它們應該需要保留起來,並公開這些資訊給團隊成員,這也算資訊透明化的一部分。

另外編譯過的檔案,通常會是發佈時才需要保存和記錄版號。除了可以 rollback 外,如果其他團隊只需要結果(如用 Go 寫了一個小工具)而不需要參與開發時,這些資訊有公開就會令大家非常開心,合作上也會減少更多阻礙。


今日回顧

一個階段完後,參考結果再決定下一個階段如何開始,這樣就是一個簡單的 Pipeline 的概念。

開發人員提交了一包原始碼後,每過了一個階段,這包原始碼感覺就越沒問題。到了最後一步準備要 Deploy 前,相信大家都對這包發佈用的檔案是極有信心的,而不會再是「上線即祈禱」了。

相關連結


上一篇
Build Script
下一篇
CI 工具大亂鬥
系列文
CI 從入門到入坑30

尚未有邦友留言

立即登入留言