[淺談]企業如何抉擇DevOps平台或工具

在一些研討會中，分享DevOps推行經驗外，最常會被問到一個問題就是可以推薦好的DevOps工具或是你們都是用什麼DevOps工具 。每次，被問到這個問題，說真的，實在很難有一個好的答案。畢竟每個企業環境不同、文化不同以及政策不同，我的好並不一定代表你就可以適用。尤其，是在DevOps越來越盛行情況下，各種廠商都會推出自己所謂的DevOps工具，或是所謂的平台。也造就很多人不知道該怎樣選擇。據說Salseforce也推出屬於他們專屬的DevOps平台，但這平台其實做多充其量就是針對它們產品做CI/CD上更方便而已

從下圖我們可以發現市場真的很多這樣工具與平台。我相信這張圖還不一定有包含更多其他的工具。

從最老牌Jenkins、Jira到Azure DevOps，甚至，大家也常在用的Gitlab、GitHub...等，這些都可以屬於DevOps工具平台。無論是在自家建立或是採用雲端SaaS服務，還真的包羅萬象。每一個工具都有自己的強項，如果是屬於自己玩或是小團隊來用用，要怎樣透過不同工具組出適合自己的DevOps工具鏈，都是可以。但是，站在企業的角度，可能就不一定是這樣回事。

在企業內的IT或是開發人員的時間都是寶貴的，大多時間都專注於商業流程的系統開發。也因此越來越多企業在導入DevOps工具，就開始希望是一組All in One 的平台而非是拼裝的平台。其中，最重要一個原因就是時間成本，通常拼裝的平台或許可以呈現出強大的火力，畢竟，每個工具的優點和特色都有自己的強項 (不然也不會拿出來賣錢)。但是，這時候就必須花費的企業內部的資訊人員時間與精力進行異質平台整合，因為，必須深知這些工具的功能與如何間接其他平台，才有辦法做串接。我們都知道在異質系統整合是相當耗費時間，又加上當我們需要將資料串連時候，那就必須花更多時間進行資訊整合。如果每個工具又因為升級導致整合出現問題。IT人員就要花非常多時間成本處理。之前最常遇到是整合過程剛好是兩家不同產品，造成雙方的公司都不承認自己產品問題，導致必須花很多時間去溝通和找相關解決方案處理。

如果企業的老闆們對於這樣現象與花費成本可以認同也覺得是值得，基本上問題都不大。但是，據我所知，往往認知是相反，反而會詢問為什麼要把時間浪費在這些工具上面，這些工具不是因該很簡單且容易就可以用嗎?。花這些工具時間，導致專案進度無法完成或。這時候，IT人員只能晚上默默修復平台或是做更多客製化整合。而這些工具導入初期其實都看不任何問題的

所以，我覺得可以從幾個方位思考DevOps平台選擇或是切換:

• 現在是否已經有在使用很完整的DevOps工具鏈(只有CI / CD不算)
• 所有資訊是否在DevOps工具鏈中都能互相整合與搭配
• 投入多少人力與資源在DevOps工具鏈的建置與維運
• 上層主管會認為DevOps工具重要性等同於其他商業系統
• DevOps工具鏈的使用是否是彈型/方便/簡單
• 從DevOps運行流程，選擇可以配合自己流程的工具平台

如果本身已經有一套用的很順暢且日常維運壓力和耗費的人力成本或是相對資源也很少的DevOps平台，外加上本身使用上沒有任何痛點。其實，也不需要特別切換到所謂熱門的工具或是平台。因為，平台的切換成本是相當大的，尤其，當你已經很多資料都在原本平台上的時候。但是，如果發現當團隊或是整個DevOps體系越走越後面，且也越來越龐大。目前的工具已經無法符合人和流程的變化。這時候，也可以開始考慮是否要換工具了。通常遇到比較極端的會是有可能因為被原本工具或是平台限制，導致無法朝向DevOps之路前進。

但如果本身沒有正在運行很穩或是規模很大的平台工具，就可以考慮轉換空間，這邊規模很大不是說一套版控工具裡面只有放了大量程式碼就是規模很大。而是整體流程與運行是否已經穩健。因為，我往往看到是大家想要版控就弄一個Git Server，想要做看板或是需求管理就弄一套Jira或是其他工具。並沒有一個系統性的思考，等開始進行想要跑敏捷或是DevOps，才開始要把這些工具的資訊或是流程給串接起來，甚至可能再花一堆時間進行客製化。通常往往就需要花大量成本與人力。

講了這樣多，All in One的平台工具絕對沒有拼裝的火力強大(拼裝好的話)，但是卻可以省卻許多時間和心力去處理組合的問題。如果，企業組織有一個團隊或是部門，專職在於組裝強大火力的DevOps平台，那樣是否要用All in One平台似乎也不是那樣重要，雖然，All in One平台也可以與其他工具整合。就我所知道，很少有工具可以有專職部門或是團隊可以全職做這件事情的。

最後，回到常常在DevOps相關研討會講的，工具絕對沒有最佳的，只有是不適合組織或是團隊運行的模式。團隊合作與流程是不能被工具而遷就，不然就會喪失DevOps原有的理念。