實踐 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 囉.......