CI 常常失敗？多是這 5 大緣由…

本文翻譯自文章 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 官方技術博客。