理想情況下，當(dāng)構(gòu)建失敗時，我們是不能允許軟件繼續(xù)發(fā)布到生產(chǎn)上。但是，持續(xù)集成的理念并未貫徹到每一個敏捷團(tuán)隊。有些團(tuán)隊非常嚴(yán)肅地對待CI實踐，有些只是為了敏捷而做，有些則完全忽略CI流程，甚至有的連CI服務(wù)器都沒有搭建。 　　有很多種原因?qū)е聢F(tuán)隊忽視CI流程。工作有不同的優(yōu)先級，產(chǎn)品經(jīng)理不理解代碼質(zhì)量，測試流程和完整構(gòu)建的重要性。技術(shù)經(jīng)理無法分配足夠的時間實施CI或者修正出問題的CI。產(chǎn)品和技術(shù)管理層互相不理解各自的優(yōu)先級以至于最后部署的是構(gòu)建失敗的產(chǎn)品。 　　這個方法短期看沒什么問題，但其實非常危險。可能會導(dǎo)致產(chǎn)品有嚴(yán)重的缺陷，從而影響業(yè)務(wù)運(yùn)作。這種影響是不可預(yù)測的，可能是金錢的損失，也可能是企業(yè)聲譽(yù)，最極端的可能導(dǎo)致整個業(yè)務(wù)完全流失。 　　然而，即使產(chǎn)品經(jīng)理和技術(shù)團(tuán)隊愿意投入時間和金錢來實施CI和修正CI問題。一些團(tuán)隊還是從未成功。我們在這里討論一下CI失敗的5大原因和克服這些困難的推薦解決方案。 　　1. 錯誤地選擇CI服務(wù)器 　　市場上有很多種持續(xù)集成工具。CI服務(wù)器可以在云端也可以在本地。這里可以推薦一堆CI服務(wù)器（https://www.slant.co/topics/799/~continuous-integration-tools）。Jenkins是其中之一，但過去人們都盲目地使用它。為了適應(yīng)Jenkins，我們時常不得不更改項目妥協(xié)?，F(xiàn)在，情況有所改變，市場上出現(xiàn)了多種不錯的CI服務(wù)器。面對如此眾多的產(chǎn)品，選擇適合自己所需的的確是一項挑戰(zhàn)。 　　搭建CI服務(wù)器需要耗費(fèi)大量的時間和金錢。如果沒有提前研究就貿(mào)然決定，那么前期的投入都付之東流。管理層經(jīng)常犯的一個錯誤就是選擇一款通用型CI服務(wù)器或者適用于所有平臺的服務(wù)。設(shè)想一下，你的應(yīng)用包含Web網(wǎng)站、IOS app、Android app，用一個通用CI并不是一個很好的辦法。我們必須非常小心來選擇CI服務(wù)器。 　　推薦解決方案 　　仔細(xì)研究市場并通過實驗權(quán)衡各種選項。Slant上已經(jīng)對主流的各種CI產(chǎn)品（https://www.slant.co/topics/799/~continuous-integration-tools）有優(yōu)劣評估。關(guān)注特性，例如容器支持，平臺支持，易用型，可用性等等。不要為了試圖省錢采用一款通用的適應(yīng)所有平臺的CI產(chǎn)品，每一個平臺都有不同的技術(shù)需求和挑戰(zhàn)。和團(tuán)隊討論并借鑒過去的經(jīng)驗。 　　2. 業(yè)余工程師 　　在敏捷團(tuán)隊的每一位工程師都有很強(qiáng)的編程能力。但僅僅是是寫代碼和測試代碼是不夠的，還需要搭建環(huán)境的能力，運(yùn)行命令行和編寫腳本的技能，還要具有對各種構(gòu)建工具和軟件包管理工具的扎實的知識。 　　最近，很多公司都開始講IT架構(gòu)遷移上云，所以還需要 Devops 技能。例如，AWS、AZure、Heroku，各種配置工具例如：bash、Ansible和 Chef，還有容器Docker and Kubernetes。最重要的是要具備至少一種腳本編程能力，比如Bash、Ruby或者Python。這當(dāng)然并不意味者你需要學(xué)所有的東西，但你需要了解平臺上的所有東西。假設(shè)一位從事IOS開發(fā)的工程師，他就需要了解各種相關(guān)的工具例如：Cocoapods、Carthage和Swift Package Manager。還有用于構(gòu)建的工具，例如在APPLE 命令行工具之上的Fastlane、Rake和Make。 　　術(shù)業(yè)有專攻，有些工程師擅長基本編程語言，比如 Java、Objective-C和Swift，并且對DevOps相關(guān)的各種工具相當(dāng)熟悉。 有些工程師則習(xí)慣于使用IDE環(huán)境開發(fā)（比如Eclipse、IntelliJ和Xcode），他們不太熟悉使用終端敲入命令。還有些工程師擅長構(gòu)建工具但寫程序代碼則弱一些。所謂業(yè)余工程師是指那些只會在IDE環(huán)境下編程，不會使用命令行和腳本工具的人，他們只喜歡使用GUI去做事而抗拒使用命令行或腳本。但是，CI服務(wù)器并沒有GUI，所有的事情都只能用腳本來完成。如果你的團(tuán)隊有這類人，那CI就永遠(yuǎn)不可能成功，他們可能會開發(fā)一些質(zhì)量低劣的自動化腳本，然后大家的時間都花在差錯，該機(jī)和CI服務(wù)器切換上，而不是真正構(gòu)建對業(yè)務(wù)有意義的功能。 　　推薦解決方案 　　招聘具有CI和DevOps基礎(chǔ)知識的工程師。培訓(xùn)工程師，最好的辦法是送他們?nèi)ネ饷媾嘤?xùn)或者請內(nèi)部有經(jīng)驗的CI專家培訓(xùn)。短期招聘一些CI專家來建立CI流程和分享經(jīng)驗。 　　3. 隨意更改CI服務(wù)器配置 　　許多CI服務(wù)器允許用戶通過Web界面去更改CI服務(wù)器配置。這個方法對工程師而言的確比較方便。但是經(jīng)常更改CI配置也會產(chǎn)生很多問題，比如把一些很重要的步驟錯誤地忽略掉。而且，如果每個人都有權(quán)限在上面更改的話，最后就搞不清楚誰，什么時間做了什么更改。當(dāng)查錯的時候，都需要花費(fèi)大量的時間。經(jīng)常性地更改CI服務(wù)器會導(dǎo)致很多問題。 　　推薦解決方案 　　把配置文件，腳本和其他相關(guān)文件都放到代碼庫集中管理。避免手工更改CI 服務(wù)器的配置?？刂圃L問CI 服務(wù)器的權(quán)限。不允許用戶更改一些特定的構(gòu)建步驟。 　　4. CI服務(wù)器性能差 　　在開發(fā)過程中，程序員需要經(jīng)常更新代碼，這會不停地在CI服務(wù)器上觸發(fā)重構(gòu)流程。這意味著CI服務(wù)器需要不斷地運(yùn)行大量作業(yè)。例如從遠(yuǎn)端服務(wù)器下載，備份數(shù)據(jù)庫，運(yùn)行Docker容器等等，所以CI服務(wù)器必須快速，可靠，網(wǎng)絡(luò)穩(wěn)定。低配的CI服務(wù)器會影響整個構(gòu)建流程，導(dǎo)致時間延長，測試時斷時續(xù)，從而浪費(fèi)大量的時間。 　　推薦解決方案 　　采用高配服務(wù)器。不要在CI服務(wù)器上安裝不必要的軟件。不要把CI服務(wù)器掛在Wifi上?？茖W(xué)地調(diào)度在CI服務(wù)器上跑的作業(yè)。不要手工安裝軟件。避免使用GUI連接 CI 服務(wù)器，使用SSH足夠了。 　　5. 缺乏管理 　　項目管理在整個CI實施中起到關(guān)鍵作用。必須對整個構(gòu)建流程設(shè)定嚴(yán)格的指引，同時對任何不遵守指引的行為零容忍。在任何情況下都不能發(fā)布CI流程中斷的軟件。任何構(gòu)建中斷都要被視為緊急事件并以最高優(yōu)先級進(jìn)行修復(fù)。很多技術(shù)經(jīng)理可以做到這一點，但一些沒有CI經(jīng)驗的管理人員可能會命令繼續(xù)開發(fā)而不顧代碼質(zhì)量。如果這樣管理，CI實施則不可能成功。 　　推薦解決方案 　　建立CI流程并嚴(yán)格執(zhí)行。培訓(xùn)項目經(jīng)理并用于CI實施。