本文翻譯自文章 Top 5 Reasons for CI Failure ，主要介紹了 CI 失敗的五個原因，包括 CI 服務的錯誤選擇、CI 工程師的不專業性、隨意更改CI服務器配置、CI服務器性能差、缺乏管理等。由 flow.ci－Meng 編譯整理。
敏捷開發不可能完美，必須有 CI 實踐的助力。CI 是持續進行分析、構建、測試和部署的自動化流程，在正式發佈到生產環境之前，CI 會檢查代碼質量和測試產品的業務邏輯。
理想情況下，在構建失敗時不能讓項目或軟件部署到生產環境。但是，持續集成的理念並不被每一個敏捷團隊適用。一些敏捷團隊非常重視 CI 實踐，有的只是爲了做敏捷而做，而有些團隊完全忽視CI，更有甚者從未配置過 CI 服務器。
在團隊中導致CI實踐被忽視有各種原因。 我們都知道企業具有不同的優先級，產品經理可能並不理解內部質量、測試流程和完整構建的重要性。 技術經理不能分配時間來實施 CI 實踐或修復出現問題的 CI 系統。 產品和技術經理無法瞭解彼此的優先級，導致部署了一個失敗的產品交付給終端用戶，並傳遞了一個非常糟糕的商業價值。
這種方法看似沒有問題，但其實非常危險。可能不久的將來會導致嚴重的產品缺陷，從而嚴重影響業務運作。這種影響是不可預知的，一開始是金錢的損失，直至影響到企業聲譽，最後可能直接導致整個業務完全失敗。
然而，即使產品經理和技術團隊同意投入更多的時間和金錢實施或修復 CI 問題，一些團隊仍未成功。 這篇文章我們討論了 CI 失敗的五大原因，並提供一些潛在解決方案，希望能夠幫助你。
1. CI 服務的錯誤選擇
市場上有各種持續集成工具，CI 服務器解決方案可以是本地搭建也可以雲端託管。這裏列出了一堆的 CI服務器解決方案 。
Jenkins 是目前流行的 CI 服務器之一，大家都傾向於盲目使用它。爲了使用 Jenkins 的服務，我們不得不調整項目。現在，市場上出現了一些不錯的CI服務(國內如 flow.ci )，選擇適合自己適合需求的CI服務確實是一個挑戰。
推薦解決方案：
-
仔細調研市場並通過實驗權衡各種需求，Slant上已經對 主流的各種CI產品 進行了很詳細的優劣評估，可參考一下；
-
關注特性，例如管道支持，容器支持，平臺支持，易用型，可用性等等；
-
不要爲了節省開支而選擇一款通用的適應所有平臺的CI產品，每個平臺都有不同的技術需求和挑戰；
-
和團隊討論並借鑑過去的經驗。
2. 業餘的 CI 工程師
敏捷團隊的工程師應該具有出色的編碼能力，但僅僅寫代碼和測試代碼是不夠的，還涉及搭建配置環境的能力，運行命令行和編寫腳本的技能，還要有對自動化構建工具和依賴/包管理工具的知識儲備。
最近，很多公司開始把基礎設施轉移到雲端，所以還需要學習DevOps的技能，比如AWS，Azure 和 Heroku 等雲服務。配置工具，如bash，Ansible和Chef；以及 Docker 和 Kubernetes 等容器服務。最重要的是掌握至少一種腳本語言，即Bash，Ruby或Python。
這並不意味着你應該學習世界上的所有東西，但你需要了解平臺上的東西。假設一名 iOS 開發工程師，可能需要知道Cocoapods，Carthage 和 Swift 等依賴管理工具。
還有用於構建的自動化工具，如在 APPLE 命令行工具之上的Fastlane，Rake和Make，並關注最新技術發展。
每個工程師都會有擅長的東西，有的擅長編寫基本編程代碼（即Java，Objective-C和Swift），並對 DevOps 相關的構建自動化工具非常熟悉。有的工程師習慣於使用IDE環境開發（比如Eclipse、IntelliJ和Xcode），有些工程師擅長構建工具但寫程序代碼則弱一些。
這裏說的CI業餘工程師是那些無法脫離IDE，不會使用命令行和腳本工具的人。他們只喜歡GUI工具，拒絕使用命令行或腳本。但是，CI服務器並沒有GUI界面，所有的流程必須通過腳本完成。
如果你的團隊有這類人，那CI實踐永遠不會成功。 他們可能寫出一些低質量的自動化腳本，大家的時間都浪費在改進構建自動化以及CI服務器之間的切換上，而不是真正構建對業務有用的功能。
推薦解決方案：
-
招聘具有CI和DevOps基礎知識的工程師；
-
培養CI業餘工程師，最好的辦法是去外部培訓或者請內部有經驗的CI專家培訓；
-
短期招聘一些CI專家來建立CI流程和分享經驗。
3. 隨意更改CI服務器配置
大多數的CI服務器允許用戶通過 Web 界面更改構建的配置。 這種方法使工程師輕鬆創建和編輯 CI 工作流。 但是經常更改構建配置可能會產生很多問題，例如忽略的一些重要的構建步驟。 還有，每個人都有訪問構建機器的權限，這可能會導致混亂， 搞不清楚誰在什麼時間做了什麼更改。當互相不知道更改配置的內容，可能需要花費很長時間才能定位到構建失敗的原因。頻繁更改 CI服務器可能會導致團隊內的混亂。
推薦解決方案：
- 配置文件，bash腳本或其他相關的文件放在代碼庫中集中管理；
- 避免手動更改CI服務器上；
- 控制CI服務器的訪問權限，並由專人負責管理；
- 不允許用戶修改特定的構建步驟；
4. CI服務器性能差
在項目開發過程中，開發人員經常需要更新代碼，這會觸發CI服務器上的構建流程。 這意味着CI服務器需要持續運行大量任務，例如從遠程服務器下載相關文件，備份數據庫，運行Docker容器等，因此CI服務器必須快速可靠 ，並且穩定。 性能差的 CI 服務器不但浪費大家的構建時間，導致測試結果斷斷續續，也會影響讓工程師們士氣沮喪。
推薦解決方案：
- 選擇更好更高配的服務器；
- 不要把CI服務器掛在Wifi上；
- 不要在CI服務器上安裝不必要的軟件；
- 科學調度CI服務器資源；
- 不要手動安裝任何軟件；
- 避免使用GUI訪問機器，使用 SSH 訪問即可。
5. 缺乏管理
項目管理在整個CI實施中起着關鍵作用，必須對整個構建流程設定嚴格的指引，同時對任何不遵守指引的行爲零容忍。在任何情況下都不能發佈CI流程中斷的軟件。任何構建中斷都要被視爲緊急事件並以最高優先級進行修復。很多技術經理可以做到這一點，但一些沒有CI經驗的管理人員可能會命令繼續開發而不顧代碼質量。在這樣的管理下，CI實施不可能成功。
推薦解決方案：
- 建立團隊的CI流程並嚴格執行；
- 培訓項目經理並用於CI實施。
結語
在敏捷團隊中實施CI是非常有挑戰的，但遵循一些嚴格的規則並避免常見錯誤可以更有效地實施CI流程。你在CI實踐中有什麼樣的經驗？你覺得CI流程有效嗎？歡迎分享你的觀點！
flow.ci ，融入了 workflow 機制的持續集成（CI）服務，也可以理解爲自動化流程平臺，除了集成代碼、編譯、測試之外，還可以集成常用的工具、靈活自定義流程。本文由 flow.ci－Meng 翻譯整理，想閱讀更多技術文章，請訪問 flow.ci 官方技術博客 。