敏捷開發與高效維運的結合–DevOps

作者/陳佳宏

作者簡歷 畢業於政治大學資訊管理研究所，現任職於凌群電腦技術支援處。專長包含以C#、Java等語言的程式撰寫，使用SQL Server、Oracle等資料庫管理工具，運用Hyper-V、VM Ware等虛擬機工具做系統環境的維護及管理。專案經歷包含證券交易所、中華電信、警政署、刑事局、臺灣鐵路局等多項開發案及維護。 前言 DevOps是目前在IT界很活躍的名詞，許多網路科技公司及知名企業都在探討DevOps的方法及應用，而DevOps究竟是什麼呢?為何各企業都對DevOps抱有新的期待?因為DevOps的宗旨是，開發與維運團隊合為一體，讓團隊可以提高運作的效率。所以在DevOps工具的協助下，讓開發至維運得以成為完整的流程。在傳統的軟體開發及系統維運兩個單位各自獨立，也因為部門之間的區隔，形成了Wall of Confusion，讓雙方部門之間的互動有些隔閡，為了讓整個開發活動在這幾個參與的單位之間，形成更有效率及生產力的程序，轉化部門之間的對立為正向的互助合作，dev2ops.org提出DevOps，也就是英文「開發Development」和「維運Operations」的組合，希望能補足目前開發流程的不足。 DevOps怎麼興起的? DevOps可以說是起源於一個人腦中的疑問，逐漸演變成眾人一起探討的技術議題。這個人正是一位比利時籍的IT顧問Patrick Debois。在2007年，敏捷式開發剛剛興起，許多公司紛紛採用這模式進行開發。當時Patrick Debois正與政府部門合作，共同進行資料中心遷移的計畫，而他則負責相關測試工作。這時的他常常在開發團隊以及維運團隊間變換角色。前無一天才在敏捷式開發的模式下開發系統，隔天卻又要確保系統能正常維運。經歷此項計畫後，Patrick Debois才意會到，開發團隊與維運團隊不僅中間像隔了座山，互動方面還有各種衝突。 在2008年時，在多倫多的Agile研討會上Patrick Debois與Puppet實驗室共同創辦人Andrew Clay Shafer，兩個人針對敏捷式基礎建設(Agile Infrastructure)這主題相談許久，他們兩個人都認為可以思考出一個方式，搭起開發團隊與維運團隊之間的橋樑。在當時，持續整合（Continuous Integration）的想法已經逐漸開發社群間發酵，並且應用在部署服務的方面，但是此觀念還尚未應用在維運團隊中。 2009年6月23日，在加州聖荷西O'Reilly Velocity大會上，來自Flickr的資深技術維護員John Allspaw以及領導工程師Paul Hammond，在會議中分享的主題為「10+ Deploys per Day：Dev and Ops Cooperation at Flickr」。這主題真是讓各開發者震驚不已，因為一天內部署超過10次是多困難的任務。此演講很快速地受到社群的認同，因為他們證明了開發團隊與維運團隊彼此是可以順利合作。John Allspaw跟Paul Hammond認為打造新一代軟體的方法應該是讓開發團隊及維運團隊兩個都變得透明，並將兩者互相整合在一起。這也正好與Patrick Debois的想法不謀而合，隔著大西洋觀看直播的他在Twitter上表示，如果能親臨現場該有多好，而很快地就有人回覆他的Twitter，建議他也於比利時舉辦一個活動讓大家來參加。雖然是Twitter好友的一句玩笑話，讓Patrick Debois決定開始籌組自己的活動，卻也得到大家的共鳴，消息在社群網路蔓延開來。 也就這樣Patrick Debois在2009年10月30、31日在比利時根特城舉行了「DevOpsDays」的活動。活動結束後，DevOps的話題依然持續在Twitter上延燒。很快的，DevOpsDays走出了比利時，成為定期舉辦及吸引開發社群參與的全球會議。而且在John Willis、DTO Solutions創辦人Damon Edwards及Puppet實驗室共同創辦人Andrew Clay Shafer等人的幫助下，美國也舉辦了第一個DevOpsDays。另一個有趣的觀點可以看出，DevOps可以說是第一個由社群網路發起的科技運動。由一個Twitter的hashtag(#devops)，在社群網路上蔓延至全世界，這也為DevOps增添了一點獨特的話題。 看到DevOps在各地蓬勃的發展，許多知名分析師也開始撰寫相關文章並鼓吹DevOps的觀念。其中Gartner研究副總裁Cameron Haight在文章中預測，在2015年，全球兩千企業中的20%會擁抱DevOps。來自451研究機構的分析師Jay Lyman呼籲，如果企業想針對客戶、軟體開發有更快速的反應，勢必要導入DevOps。此外，O'Reilly內容策略副總裁Mike Loukides亦撰文「What is DevOps？」他認為DevOps是對於開發團隊以及維運團隊兩者之間都有深入、貼近地了解。DevOps相關的書籍開始變得熱門，如Tripwire創辦人Gene Kim、Gartner研究總監George Spafford等人共撰的《The Phoenix Project》及Chef副總裁Jez Humble及軟體開發者Dave Farley共筆的《Continuous Delivery》。 除了IBM、Red Hat、Microsoft等科技業外，梅西百貨Macy’s、手工劍橋包公司 Cambridge Satchel 及迪士尼也紛紛擁抱DevOps。根據Puppet實驗室、IT Revolution及ThoughtWorks的調查，有16%約1,485位受訪者表示，目前所屬企業已經建立了DevOps團隊。在2014年，第一場以企業為導向的DevOps企業高峰會也在加州開始舉辦。 DevOps的概念及作法 傳統系統開發部門( Developers )與系統維運部門( Technology Operators ) 兩個單位之間的隔閡，各單位傾向於維護自己單位的利益。像是系統維運部門為了求系統穩定，通常會竭盡所能的阻擋新版程式的更新，因為任何更新就有可能會使系統衍生不確定的問題，而不穩定的系統又通常會歸咎於維運單位的身上，而如果到最後找出來的問題是來自於開發單位的錯誤、更新程序的說明文件不足或是新版程式測試不完整，這種種可能的原因，上線後都得要讓客服與維運人員承受客戶的壓力，惡性循環下，讓兩個單位之間的高牆更高、更難跨越。 而開發單位需要更新程式，最常發生的原因主要來自業務單位的需求，這也是業務跟開發之間的高牆，開發單位需要有個開發的程序，用來管理客戶需求跟開發的步驟。而這個部份是一直以來被討論最多的，從傳統的方式是「瀑布式開發法 Waterfall」，後來進化到「統一軟體開發過程Rational Unified Processing」，直到最近幾年被廣泛應用的「敏捷式開發Agile Development Process」。 而DevOps將開發活動從客戶需求到實際的開發與測試，延伸到最後維運單位的系統更新與上線，DevOps 也可看成是開發、QA與維運三個單位的交集。目的是要透過強調溝通 ( Communication ) 、合作 ( Collaboration ) 、整合 ( Integration ) 及自動化 ( Automation ) 等方式加強開發人員 與維運人員還有其他包括質量控制等人員之間的合作。DevOps 就是要解決系統發布與更新的問題，解決的方式就類似由Waterfall轉變到 Agile development 的過程，可以解決系統長時間更新上的問題，導入DevOps帶來的影響如下 一、減少變更範圍： 每天或每週更新一次，減少更新帶來的變化，更新的速度更頻繁，讓系統開發與維運的活動更熱絡，養成工作習慣的 routine，少量更新也讓所有人員更容易找出發生問題的地方。 二、加強發布協調：： 以發布協調人員居中協調系統開發與維運之間的橋樑，採用各種協調互動的工具，讓所有人了解系統更新的程序與內容。 三、自動化： 自動化部署程序，確認可重複性的系統更新，減少出錯的可能。 其實DevOps也有助於發行管理，強調快速與自動化的部屬與驗證，讓開發部門與維運部門互助合作。 DevOps工具的使用及成效 DevOps發展至今可以說是百家爭鳴，各個知名的分析師都用不同的角度探討DevOps這新名詞。當然各科技大廠也沒放過這機會，紛紛發展出DevOps工具讓這概念能徹底在企業上執行，像是Microsoft、HP、IBM都擁有自己對DevOps的定義與解決方案，本文以微軟的應用程式生命週期管理(ALM)作主要的介紹。 Microsoft透過Visual Studio Team Services(VSTS)來讓軟體開發組織掙脫了將開發、測試、專案管理和營運小組隔離之嚴格的程序導向應用程式開發週期。VSTS是位於雲端版本的軟體生命週期管理(ALM)軟體服務，透過VSTS可以進行版本控管、工作項目維護、Features和Bugs的 tracking，雲端的自動化建置與測試...乃至於CI(持續整合)與CD(持續部署)，所有動作皆可在VSTS上進行。 VSTS所提供的功能如下： 一、敏捷式規劃： 使用內建的工作流程看板規劃及監視您的所有團隊工作 (包括作業問題)。 追蹤進行中的工作，以確定您可以透過簡化的方式將概念轉換為最終交付項目。並且可以搭配可設定的看板使用拖放待處理項目管理，為參與專案的每個小組設定重要工作的優先權並加以視覺化。 現成的 Scrum 支援將協助規劃、管理小組產能，以及追蹤工作面板和燃盡圖的進度。 二、原始檔控制： 所有的程式碼變更都會和工作執行相關的案例、Bug 或工作直接相連。都可以由 Visual Studio Team Services 上進行追蹤，可以讓專案成員可以充分掌握程式碼庫的各種變動。 三、測試： Visual Studio 提供工具，以協助您的小組自動化測試、通過手動和探勘測試，以及執行負載和效能測試。 擷取內容中的豐富資訊，讓您重現 Bug，並確保整個開發程序的品質。 從探勘回合自動產生測試案例、建立及管理多個測試組態，以及透過螢幕和語音擷取來錄製使用者動作，改善應用程式問題點的重現性。 四、部屬版本： 軟體部署的速度越快，就能越快取得意見回饋。 透過 Visual Studio 中的發行管理，您可以針對任何環境設定、核准及部署應用程式。 無論組態有多複雜，都能針對各環境建立自動化的部署協調流程。更頻繁且更輕鬆地將軟體交付到環境，可讓您的測試人員開始驗證系統並使共同工作人員參與提供意見回饋。 五、跨平台： 如果團隊正在開發不同平台的軟體，並且使用各種開發人員工具，例如 Eclipse 和 Xcode，整個開發小組仍然可以透過 Visual Studio Team Services 或 Team Foundation Server 中的應用程式開發週期管理服務利用單一、統一且彈性的共同作業環境。 Team Explorer Everywhere將 Team Foundation Server 和 Visual Studio Team Services 的功能提供給在 Eclipse中進行開發的小組。另外還可以連接至內部部署或雲端中的 Team 專案，以完整存取原始程式碼、待處理項目和非Windows 平台的建置功能。 Visual Studio 的全球合作夥伴生態系統也提供大量額外的跨平台功能，例如Xamarin可用於建置Android 和 iOS 裝置上的原生應用程式、重複使用您的 .NET 程式碼，並與 Visual Studio 完全整合。 DevOps是個文化 DevOps從字面上的意義來說，就是研發工程師和維運人員一起參與，在產品的整個服務生命週期中，從設計到開發過程中，全程支援產品的做法。維基百科上的說明為；「DevOps(英文Development和Operations的組合)是一組過程、方法與系統的統稱，用於促進開發(應用程序/軟件工程)、技術運營和質量保障(QA)部門之間的溝通、協作與整合。」不過在英國政府數位服務手冊上的定義：「DevOps 是一種組織內文化與既有職責變革(movement)，用以解決大型組織內常見的分工問題。」 這是一種有趣的現象，因為所有的科技大廠都在開發自己的解決方案，也就很容易讓人誤解它是一種開發方法，不過DevOps並沒有任何規範，也沒有描述任何解題的步驟，因此絕對不是一種方法。基本上要作到DevOps，是一串繁複的過程，要先一層層的打通原本的障礙，但真正難的是持續維護的作業。它牽扯到的是企業的文化，這是一種文化層面的東西，所以必須由改善企業文化來解決問題。這跟敏捷開發強力推廣的宣言一樣，「個人與互動重於流程與工具」。其實DevOps的目的是要一個團隊，「先弄清楚自己要做什麼事、為什麼這樣做、這樣做了能解決什麼問題」，強調運用會議和溝通來找到真正的問題並建立共識才更重要，目的是讓團隊先去弄清問題，再思考解決問題需要那些流程跟工具。 在傳統的組織架構當中，人人可能只關注在自己的領域與工作，但是在一個開發流程當中除了 coding 之外，後續還有測試、部屬、維護...等，因此難免會與其他成員有互動，或是跨部門的合作，光是專注於自己的工作也不能保證不會影響到別人。DevOps 真正的核心價值正是文化，建立一個強調合作、協作、負責任及分享的文化。讓成員們同心協力的將專案完成。 參考資料 1.為什麼會出現DevOps？ 2.The History Of DevOps 3.什麼是DevOps? 4.Visual Studio應用程式生命週期管理