fbpx

實踐 DevOps 讓你的 Bug 看起來都一樣

DevOps Agile

實踐 DevOps 重開發環境建置開始

軟體開發必備開發環境,在一般的情況下,我們會希望這個開發環境與實際上線的 Production 維運環境越接近越好。最好是一樣的系統、一樣的核心、一樣的編譯器 (或直譯器)、一樣的函式庫等等,盡力確保我們的程式 (或Bug) 可以完美地被執行。敏捷開發提及的持續整合精神一直很重視開發、測試、維運環境之間的一致性,好讓整合工作可以貫穿整個軟體生命週期,這幾年喊的 DevOps 概念其實在敏捷開發中早已行之有年,只是早期在沒有 Linux Container 與這麼多好用的工具幫助下,DevOps 不容易被實踐。一致的開發環境在敏捷中是相當重要的!

用一致的開發環境才酷炫

我們先想想如果沒有一致的開發環境容易造成哪些問題?

團隊成員因開發基準不同造成系統整合問題

如果每個開發者所執行程式的環境不同,常常會在系統整合時發生困難,雖然透過第三方公平地持續整合 (Continuous Integration) 系統可以降低這個問題,但是一旦軟體無法完全正常執行於其他人的開發環境中,依然會讓產品進入測試前的系統整合工作造成阻礙。比如同事寫的 Library 相依了 CPU 位元架構,造成需要整合程式的另一位開發者無法順利執行。

不一致的環境讓測試工作變得不紮實

測試階段最常遇到的鳥問題,就是神出鬼沒難以被重現的 Bug  (在我電腦不會啊),常常 Bug 只發生在測試環境問題,實際後來發現可能是漏裝了 Library 第三方套件之類的蠢問題,然後軟體上正式站又再忘記一次,每天都在 De 一樣的 Bug (總覺得這蟲好熟悉啊!!)。軟體設計過程中,常常容易忽略程式碼以外的系統參數或設定,或著第三方套件版本相容性不佳、設定檔忘記更改、系統參數忘記調整、Runtime 直譯器版本差異等等問題,造成軟體在測試與開發階段中,產生太多無謂的來回程序 (Bug 總是驗不過)。最終使得產品釋出週期延長,間接放大了市場風險,賠上了時間與機會成本。

不易攜帶與部署的開發環境讓上線更遙遠

過於複雜與不被管理的開發環境,常常增加了新進人員進入開發工作的困難,太複雜的開發環境可能光設定就要一天,更何況未來開發環境有變更時,更不容易落實到每一位開發者身上。久了之後造成團隊成員之間的開發環境不一,工作上很難交叉支援,常常每況愈下久了嚴重拖累研發進度。可攜度低得系統,常常會在部署時花上許多時間,甚至每次發布新版都要專人進行,這樣的系統交付方式是很不健康的。常常讓產品推出上線後,營運成本不斷提升。

關於好的軟體開發環境架構

一個好的軟體開發環境架構有哪些特性?經過幾年踩雷的經驗,我歸納了一些我還記得的開發環境特性,可以幫助大家評估團隊的開發環境敏捷程度。

擁有便利切換的設定檔管理機制

透過設定檔快速切換不同階段的系統設定,像是在開發 (Development)、測試 (Testing)、預備 (Staging)、產品 (Production) 等等階段中,可透過設定檔快速進行切換與管理。

快速且自動化進退版部署機制

新版程式上線 (Deploy) 是很重要的,同樣上線後 GG 要馬上退版也很重要,整個過程必須自動化且快速 (建議 30 秒以內完成),而且可以輕易由團隊其他成員接手部署工作。在持續整合中實現這一段自動化工作是相當重要的,可以節省很多產品交付所耗費的人力,對於持續交付 (Continuous Delivery) 與持續迭代的 Small Release (極限編程) 相當有幫助。

本機快速建構與切換開發環境的能力

很多時候我們都是遠距工作,或者到一個沒有網路連線的惡劣環境中,如果開發工作的進行必須依賴了某些 Server,像是資料庫、運算叢集、特殊作業系統等等,那麼一但無法連線到這些服務的情況時,變失去了開發能力 (只能泡咖啡了)。此外,優異的開發環境不但可以本機執行,而且可以透過 Script 或工具快速建立與切換不同專案,讓即使不懂系統全貌的工程師也能快速進入開發,好讓工程師專注在自己專業領域中 (比如前台、後台、系統、測試等等不同領域),而不是為了建立開發環境花費太多時間。

能夠持續整合與版本控制管理

最終我們期望整個開發環境的建置與測試,可以透過持續整合進行管理,所有的環境設定、建置 Script、程式碼都在版本控制系統 (Git, SVN) 中進行管理。任何新進的開發人員,只要從版本控制系統 Check Out Source,就能自行在本機進行開發工作。一但系統有了變更,可以連動持續整合進行系統回歸測試,確保軟體每一次變更的健康狀態,好讓我們決定是不是將新功能 (或新 Bug) 交付到客戶手上。

開發環境建構實踐心得

在 Linux 容器 (Container) 技術還不流行的以前,我們為了要讓開發、測試、維運自動化,起初寫了很多 Script 進行環境配置,搭配 Linux Package Manage (DEB 或 RPM Package) 機制快速發布產品到伺服器上。早期為了實現開發、部署、維運環境的一致化,甚至把腦筋動到 VM 上,但是 VM Image 實在太大,非常不易攜帶與管理。現在有了 Lniux Container 技術方便多了,上述想實現的美夢都可以透過 Docker 完成。原本我們的開發團隊使用 Script 建構開發環境,透過 Linux Package 打包與部署系統進行測試與上線,後來專案與產品線變多了,要在同一台電腦中切換不同的專案實在很不方便,有時候一個產品需要十幾個服務才能跑起來,為了解決這個問題,我們全面導入 Docker 開發環境,也解決了長久以來的開發環境建構問題。

這一篇文章本來是要介紹 Docker Swarm 來管理整個雲服務,結果發現「開還環境建構」這個議題有很有趣,只好賣個關子下次再介紹 Docker Swarm 囉.......