The DevOps Handbook:奠定部署管線的基礎、實現快速可靠的自動化測試

本文為 Ch9、10 兩章筆記

所有的東西都要進版控

版本控制系統(version control)用於記錄系統中檔案或檔案集的所有變更,其中一組變更構成一次提交(commit)或稱為修訂(revision)。每個變更與其中繼資料都會以某種方式儲存在系統中,之後便可進行比對、合併或還原至某個版本。

所有的原始檔與配置文件都要進版控,例如

這樣做的目的是

成功案例

2009 年一家澳洲大型電信公司在做企業資料倉儲專案時,當時有十個進行中的專案,進度都嚴重落後。只有一個勉強在時程內進入客戶驗收的階段(UAT),最後再花了六個月才完成 UAT,但品質低落。

推測進度落後的原因是 將系統部署到生產環境後才發現問題。也就是說,開發與測試中的程式碼和生產環境相比,只有 50% 是相同的,也就是說,許多因不同環境而修正 bug 的程式碼並沒有進入版控,導致開發環境的準備需要八週(很長)的準備時間才能開始進入開發階段。

為了縮短環境準備的時間,改善為

因此原本環境的準備需要八週的時間,就縮短為一天,順利幫助團隊的準備符合交付時程、減少交付成本和各種問題。


版控與自動化佈建環境提供自動化測試的基礎,以下來談如何 建立自動化測試的機制


提交後就馬上進行自動化測試

程式碼一旦提交後,就執行自動化測試,只有當提交通過自動化測試,才能進行部署。也就是說,自動化測試要能確保此次變更是正確的、能部署的。

這樣做的好處是

自動化測試要能快速可靠

因此要自動化的測試應該是從做可以驗證業務目標的測試、少量、可靠的自動化程式開始,然後持續提升和累積測試案例。

測試的方法有哪些

依照測試速度的快慢,自動化測試可分為以下三種。

單元測試

理想上,應花多數心力在單元測試上(最下方)。

The ideal and non-ideal automated testing pyramids

圖片來源:The DevOps Handbook

驗收測試

整合測試

確保這個應用能在生產環境中與其他應用和服務正常運作,次數愈少愈好,儘量在單元測試和驗收測試發現和解決問題。

讓自動化測試養成習慣

測試驅動開發 (test-driven development,TDD) 和驗收測試驅動開發 (acceptance test-driven development, ATDD),在寫程式之前先寫測試,步驟為

TDD vs ATDD

盡量將手動測試自動化

在測試套件中整合效能測試

效能不佳的問題往往是在整合測試或部署到生產環境中才會發現,為了及早發現效能相關的問題,建議這麼做…

在測試套件中整合非功能性需求測試

除了測試程式碼符合預期在生產環境下運作外,也需要測試系統的其他與「品質」相關的屬性,意即「非功能性需求」例如:可用性、可擴展性、容量、安全性等。

當部署管線失敗時拉下安燈索

一但某個提交的程式碼會導致自動化測試失敗或佈建失敗,在這個問題被解決前,系統不允許提交新的變更,並可選擇退回前一個版本。這個「不允許提交新的變更」就是安燈索(andon cord)。

為何需要拉下安燈索?


References


comments powered by Disqus