CI 失敗的緣由與解決辦法

理想狀況下，當構建失敗時，咱們是不能容許軟件繼續發佈到生產上。可是，持續集成的理念並未貫徹到每個敏捷團隊。有些團隊很是嚴肅地對待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