理想情況下，當構建失敗時，我們是不能允許軟件繼續發布到生產上。但是，持續集成的理念並未貫徹到每一個敏捷團隊。有些團隊非常嚴肅地對待CI實踐，有些只是為了敏捷而做，有些則完全忽略CI流程，甚至有的連CI服務器都沒有搭建。

有很多種原因導致團隊忽視CI流程。工作有不同的優先級，產品經理不理解代碼質量，測試流程和完整構建的重要性。技術經理無法分配足夠的時間實施CI或者修正出問題的CI。產品和技術管理層互相不理解各自的優先級以至於最後部署的是構建失敗的產品。

這個方法短期看沒什麽問題，但其實非常危險。可能會導致產品有嚴重的缺陷，從而影響業務運作。這種影響是不可預測的，可能是金錢的損失，也可能是企業聲譽，最極端的可能導致整個業務完全流失。
然而，即使產品經理和技術團隊願意投入時間和金錢來實施CI和修正CI問題。一些團隊還是從未成功。我們在這裏討論一下CI失敗的5大原因和克服這些困難的推薦解決方案。

1. 錯誤地選擇CI服務器

市場上有很多種持續集成工具。CI服務器可以在雲端也可以在本地。這裏可以推薦一堆CI服務器（https://www.slant.co/topics/799/~continuous-integration-tools）。
Jenkins是其中之一，但過去人們都盲目地使用它。為了適應Jenkins，我們時常不得不更改項目妥協。現在，情況有所改變，市場上出現了多種不錯的CI服務器。面對如此眾多的產品，選擇適合自己所需的的確是一項挑戰。

搭建CI服務器需要耗費大量的時間和金錢。如果沒有提前研究就貿然決定，那麽前期的投入都付之東流。管理層經常犯的一個錯誤就是選擇一款通用型CI服務器或者適用於所有平臺的服務。設想一下，你的應用包含Web網站、IOS app、Android app，用一個通用CI並不是一個很好的辦法。我們必須非常小心來選擇CI服務器。

推薦解決方案

仔細研究市場並通過實驗權衡各種選項。Slant上已經對主流的各種CI產品（https://www.slant.co/topics/799/~continuous-integration-tools）有優劣評估。
關註特性，例如容器支持，平臺支持，易用型，可用性等等。
不要為了試圖省錢采用一款通用的適應所有平臺的CI產品，每一個平臺都有不同的技術需求和挑戰。
和團隊討論並借鑒過去的經驗。

2. 業余工程師

在敏捷團隊的每一位工程師都有很強的編程能力。但僅僅是是寫代碼和測試代碼是不夠的，還需要搭建環境的能力，運行命令行和編寫腳本的技能，還要具有對各種構建工具和軟件包管理工具的紮實的知識。

最近，很多公司都開始講IT架構遷移上雲，所以還需要 Devops 技能。例如，AWS、AZure、Heroku，各種配置工具例如：bash、Ansible和 Chef，還有容器Docker and Kubernetes。最重要的是要具備至少一種腳本編程能力，比如Bash、Ruby或者Python。

這當然並不意味者你需要學所有的東西，但你需要了解平臺上的所有東西。假設一位從事IOS開發的工程師，他就需要了解各種相關的工具例如：Cocoapods、Carthage和Swift Package Manager。

還有用於構建的工具，例如在APPLE 命令行工具之上的Fastlane、Rake和Make。

術業有專攻，有些工程師擅長基本編程語言，比如 Java、Objective-C和Swift，並且對DevOps相關的各種工具相當熟悉。 有些工程師則習慣於使用IDE環境開發（比如Eclipse、IntelliJ和Xcode），他們不太熟悉使用終端敲入命令。還有些工程師擅長構建工具但寫程序代碼則弱一些。

所謂業余工程師是指那些只會在IDE環境下編程，不會使用命令行和腳本工具的人，他們只喜歡使用GUI去做事而抗拒使用命令行或腳本。但是，CI服務器並沒有GUI，所有的事情都只能用腳本來完成。

如果你的團隊有這類人，那CI就永遠不可能成功，他們可能會開發一些質量低劣的自動化腳本，然後大家的時間都花在差錯，該機和CI服務器切換上，而不是真正構建對業務有意義的功能。

推薦解決方案

招聘具有CI和DevOps基礎知識的工程師。
培訓工程師，最好的辦法是送他們去外面培訓或者請內部有經驗的CI專家培訓。
短期招聘一些CI專家來建立CI流程和分享經驗。

3. 隨意更改CI服務器配置

許多CI服務器允許用戶通過Web界面去更改CI服務器配置。這個方法對工程師而言的確比較方便。但是經常更改CI配置也會產生很多問題，比如把一些很重要的步驟錯誤地忽略掉。而且，如果每個人都有權限在上面更改的話，最後就搞不清楚誰，什麽時間做了什麽更改。當查錯的時候，都需要花費大量的時間。經常性地更改CI服務器會導致很多問題。

推薦解決方案

把配置文件，腳本和其他相關文件都放到代碼庫集中管理。
避免手工更改CI 服務器的配置。
控制訪問CI 服務器的權限。
不允許用戶更改一些特定的構建步驟。

4. CI服務器性能差

在開發過程中，程序員需要經常更新代碼，這會不停地在CI服務器上觸發重構流程。這意味著CI服務器需要不斷地運行大量作業。例如從遠端服務器下載，備份數據庫，運行Docker容器等等，所以CI服務器必須快速，可靠，網絡穩定。低配的CI服務器會影響整個構建流程，導致時間延長，測試時斷時續，從而浪費大量的時間。

推薦解決方案

采用高配服務器。
不要在CI服務器上安裝不必要的軟件。
不要把CI服務器掛在Wifi上。
科學地調度在CI服務器上跑的作業。
不要手工安裝軟件。
避免使用GUI連接 CI 服務器，使用SSH足夠了。

5. 缺乏管理

項目管理在整個CI實施中起到關鍵作用。必須對整個構建流程設定嚴格的指引，同時對任何不遵守指引的行為零容忍。在任何情況下都不能發布CI流程中斷的軟件。任何構建中斷都要被視為緊急事件並以最高優先級進行修復。很多技術經理可以做到這一點，但一些沒有CI經驗的管理人員可能會命令繼續開發而不顧代碼質量。如果這樣管理，CI實施則不可能成功。

推薦解決方案

建立CI流程並嚴格執行。
培訓項目經理並用於CI實施。

總結

在敏捷團隊中實施CI是非常有挑戰的，但是遵循嚴格的規則並避免一些常見錯誤可以有效地實施CI流程。

原文地址： http://www.linuxprobe.com/ci-fail.html

本文出自 “小華的博客” 博客，請務必保留此出處http://coderhsf.blog.51cto.com/12629645/1939615

CI 失敗的原因與解決辦法