從商業價值切入，找到實務應用的新場景，正是各產業積極發展轉型的目標。腳步較快的本土企業，近兩年開始藉由成立DevOps團隊，從實踐的過程中累積經驗，逐步調整開放原始碼套件所組合而成的工具鏈，進而藉由自動化機制，減少人力介入操作，以成功達到及時回應市場與展現價值。
Red Hat資深解決方案架構師張均合指出，切勿以為導入建置一套軟體工具即可做DevOps，實踐的本質是為了讓公司內部形成一種氛圍或文化，IT部門中不同技術領域的工作者得以自然地合作，推動應用服務快速上線運行。就像是新創公司，核心思維為了存活必須得加快速度，類似於程式開發的快速失敗（Fail-fast）概念，至於採用的工具則取決於團隊擅長的技能，並無一定的標準，況且主要技術皆來自開放陣營，版本更迭速度相當快，且實作技術不斷推陳出新，若單純仰賴工具，隨後恐面臨發展瓶頸。
工具鏈本身可視為DevOps團隊的敲門磚，藉此讓團隊成員開始熟悉彼此溝通與協同合作模式，例如運用Slack等App，工程師可透過幾個簡單關鍵字，讓後端程式碼自動執行。
自動化機制提升Pipeline流程效率
張均合進一步說明，所謂的創新，應該是由小而大、由下而上，主要因素在於，從實際接觸客戶的經驗發現，許多企業的高階主管是接收到同業正在推動DevOps，為了加緊腳步跟進，要求IT部門基於同業採用的工具鏈來執行任務，結果往往是被動式配合高層下達的指定，卻無法在實務上發揮作用。不如讓團隊自發性地感受新工具帶來的改變，先行運用到日常工作提升效率。再逐步推展小專案，從中尋找商業模式，同時也可藉此增進開發與維運者彼此之間的協同合作默契，逐步累積經驗並加以改善，經過整理收斂後，建立最合適的工作流程。
就台灣產業發展現況來看，張均合指出，DevOps發展速度較快的當屬金融業，已經充分感受到來自跨界競爭的壓力，也很想從體質面盡快著手改變，促進團隊之間合作模式、彼此的溝通，或者是直接增設DevOps架構師職務，引領團隊執行新業務需求任務。
「其實DevOps早在15年前就已經出現，只是當時稱之為Enterprise Management Control，或者是Change Management Control，概念上皆類似，如今演進到DevOps並非全新的概念。許多大型企業會找顧問或軟體廠商協助共同制定出DevOps實作方法，但是聽完高大上的目標之後，最終落地仍舊得回歸到企業內部。從我參與幾個客戶實施的經驗，就如同前述說明，必須由下而上、由小而大、由淺入深，逐步累積經驗與知識。當然，前提是要高階管理層的支持，至於如何達到目標，則是由一線單位自行創造新的工作方法。」張均合說。
Red Hat資深解決方案架構師張均合指出，Pipeline流程的工具鏈組成，主要為開源陣營發展的技術，此時Red Hat即可發揮強項，基於長期以來累積的經驗與知識，協助把關與評估，讓企業環境得以運用穩定性較高的版本發展新應用。
採用DevOps工作流程指的是程式碼從撰寫完成後直到上線運行，整體操作細節是經由Pipeline來實作，可能受到企業文化、管理政策、人員技能等因素所影響，難以將單一方法論套用到每個企業。IT廠商可協助之處，主要是改善Pipeline運行效率，減少過程中許多人為介入造成的中斷點。例如開發人員撰寫完成的程式碼，準備進入測試，傳統的做法是透過郵件通知相關人員，真正執行的時間最快通常是隔天。這段常見的工作流程，值得探討之處在於郵件溝通模式，如今已可運用像是Slack等App來提升效率，甚至根本無需通知，在程式碼簽入（Check-in）到版本控管系統當下即可觸發事前撰寫的自動化測試腳本，省去測試人員進入系統查看的動作。此即為逐步地在Pipeline中增添自動化機制，減少人力介入以提升效率。
容器化實現一次建構、隨需部署
針對Pipeline的設計，可切分為多個階段執行，不見得要一步到位。張均合以製造業客戶為例，常見的內部開發流程是基於檔案伺服器來管理，程式碼開發完成後，依照上傳的日期命名存檔，再透過郵件通知下一關測試人員。經過測試完成後，再郵件通知部署與維運人員，把此開發專案的資料夾搬移到線上的應用系統。若隔天馬上改版，就依照資料夾定義版本別，同樣動作再做一次。問題是過多的人力介入，可能發生誤刪除、存放位置出錯等問題。過程中假設有10個單位參與，即表示整個Pipeline會有10個斷點，每個斷點勢必都有改善空間，或者可予以收斂減少流程所花費的時間。
至於實作環境，則可藉助容器化之力簡化操作細節，達到快速部署與上線運行的目標。張均合舉例，開發單位常見的狀況是撰寫完成的程式碼，須在測試環境先行建構與部署，通過後進入下一個壓力測試環境，重新再建構與部署。透過容器則可做到「Build once, deploy anywhere」，意思是，程式碼一旦經過編譯封裝後，內容即無法被變更，可直接把打包封裝完成的檔案放置在各種異質環境執行，不僅省去許多無效率的操作，甚至比過去的重新建構更能夠符合金融單位稽核的需求。
依照技術掌握度組成合適工具鏈
整體Pipeline的流程，欲實作持續整合、持續發布，須由多種技術領域組成工具鏈來協助。首先是專案管理工具，由需求單位填寫申請表單，再派工給開發人員，基於.Net或Eclipse整合式開發環境（IDE）撰寫程式碼，完成後發布到GitHub、GitLab、SVN等版本控管系統；執行建構時，大多會採用Maven或Python、Ruby等的工具；進入到應用階段，可直接呼叫既有已經撰寫好的Library，整合成為可運行的應用項目，經過單元與壓力測試、弱點掃描、程式碼安全檢測，才可實際部署。
工具鏈選用的方式，須依照技術人員擅長的技能評估。其中最多被採用的Jenkins，主要是用於串連流程中的各項環節，讓建置容器環境、部署程式、上線啟用，得以自動化方式整合運行，就像是個管家的角色。
執行持續整合與持續發布過程中所選用的工具，皆可建置在容器環境，即可藉由Red Hat解決方案來奠定穩定的基礎。張均合說明，企業端建置Jenkins，過去需要採購三台伺服器，架構模式是單個Master得搭配三個Slave，可是通常只有在內部同仁提出申請單，工程師開始撰寫程式，才會觸發Jenkins執行。若為Red Hat提供的Jenkins容器化版本，則是在執行時才呼叫啟動，即可讓資源利用率發揮到極致。
【專題報導】：IT跨界合作 DevOps展價值