一、寫在前面

1、開發(fā)模式的演進(jìn)

(1) 傳統(tǒng)的開發(fā)模式

在傳統(tǒng)的開發(fā)模式下，開發(fā)、運(yùn)維、物理機(jī)三者之間的關(guān)系是非常緊密的。當(dāng)開發(fā)完成項(xiàng)目后，運(yùn)維會負(fù)責(zé)把項(xiàng)目部署到一臺物理機(jī)上，由這臺物理機(jī)向外提供服務(wù)。

由于服務(wù)和物理機(jī)關(guān)系緊密，導(dǎo)致服務(wù)非常依賴于物理機(jī)的環(huán)境。一旦需要調(diào)換物理機(jī)器，運(yùn)維同事又需要在另一臺物理機(jī)上安裝服務(wù)依賴的環(huán)境，經(jīng)過一頓折騰后，才能完成服務(wù)的部署。

(2) 容器的顛覆革命

為了解決這個問題，出現(xiàn)了一種名為虛擬機(jī)的操作系統(tǒng)虛擬化產(chǎn)品。不過還發(fā)展沒有太久，就已經(jīng)被一種更輕量級的操作系統(tǒng)容器化產(chǎn)品替代了，它就是Docker。

運(yùn)用Docker容器技術(shù)，運(yùn)維可以把服務(wù)依賴的環(huán)境資源都編入 Image 中，然后把服務(wù)運(yùn)行在 Container 上，實(shí)現(xiàn)服務(wù)與物理機(jī)的解耦。開發(fā)人員也可以將運(yùn)維的工作以可編程的方式編入 Dockerfile 文件中，從此打破了開發(fā)和運(yùn)維之間的壁壘，大大降低了部署成本。

(3) 敏捷開發(fā)的創(chuàng)新

敏捷開發(fā)把一個產(chǎn)品交付過程拆分為了多個小周期，創(chuàng)新性的通過不斷重復(fù)迭代的方式，實(shí)現(xiàn)產(chǎn)品的逐步改進(jìn)和提前交付。從此改變了以往瀑布流模式下的大周期開發(fā)問題，可以提前了解市場需求，規(guī)避風(fēng)險。

(4) Devops文化運(yùn)動

正是在基于容器、敏捷開發(fā)、CI/CD 等各種前瞻技術(shù)思想的發(fā)展下，催生了一場名為 Devops 的文化運(yùn)動。在這場文化運(yùn)動中，更加強(qiáng)調(diào)加強(qiáng)開發(fā)、測試、運(yùn)維之間的溝通?，F(xiàn)在已經(jīng)越來越多的公司或團(tuán)隊開始重視和投入到 Devops 的建設(shè)中，基于 CI/CD 構(gòu)建服務(wù)端的自動化，讓整個開發(fā)模式高效高質(zhì)量的同時，也更加流程化、規(guī)范化。

2、演進(jìn)過程中的特點(diǎn)

從上可以發(fā)現(xiàn)，隨著技術(shù)發(fā)展，RD 與測試、運(yùn)維之間的不再是涇渭分明的工作線，反而他們之間的關(guān)系愈加緊密，RD 的整個開發(fā)模式也開始向自動化方向演進(jìn)。

3、為什么要寫這篇文章

在目前的實(shí)際工作中，遇到了一系列影響效率和質(zhì)量的問題。雖然目前有現(xiàn)成的 CI/CD 機(jī)制可以使用，但它的接入成本較高且不易擴(kuò)展。

所以開始嘗試運(yùn)用 Devops 思想并結(jié)合 CI/CD 技術(shù)，創(chuàng)建一個基于CI的服務(wù)端自動化，把項(xiàng)目的開發(fā)、單測、集測、部署、檢測、監(jiān)控等整個完整的項(xiàng)目流程，都閉環(huán)集成至這個自動化中，實(shí)現(xiàn)更加快速高效高質(zhì)量地交付產(chǎn)品。

經(jīng)過一段時間的實(shí)踐，效果很好，驗(yàn)證了想法的正確性，故總結(jié)和分享此文章，為大家提供思路與經(jīng)驗(yàn)。

4、這篇文章主要寫了什么

本文會以 CI/CD 技術(shù)為核心，重點(diǎn)介紹它能為我們帶來什么，我們?yōu)槭裁匆O(shè)計自己的CI服務(wù)端自動化，以及如何設(shè)計。

5、閱讀文章前的注意內(nèi)容

• CI/CD 這項(xiàng)技術(shù)，下文中會簡稱為 CI
• 文章內(nèi)容如果出現(xiàn)錯誤理解、病句、錯別字等，請見諒并歡迎大家的指出

二、問題現(xiàn)狀

1、項(xiàng)目迭代速度快

在瀑布流開發(fā)模式下，一個項(xiàng)目的周期是足夠長的，一般有充足的時間來完成整個項(xiàng)目流程。但在敏捷開發(fā)模式下，開發(fā)內(nèi)容的縮減，伴隨而來的也是需求、測試等環(huán)節(jié)時間的縮減，導(dǎo)致迭代速度也越來越快。

舉例 ：今天需要開發(fā)一個功能，但可能不經(jīng)過測試，產(chǎn)品驗(yàn)收后就可以上線。

2、第三方工具太重

市面上流行的各種第三方工具大都非常重，功能繁多，依賴復(fù)雜，甚至還都會附帶一個后臺管理系統(tǒng)。導(dǎo)致很多時候我們只需要某個工具10%的功能，但不得不接受它90%附加的功能，這類重型工具只適合穩(wěn)定發(fā)展的項(xiàng)目。

對于快速迭代的項(xiàng)目，需要的是輕量、輕量、還是輕量！

舉例 ：接口文檔自動生成工具中，大部分都需要私有服務(wù)器部署而且會附有各種管理系統(tǒng)。

3、測試的時間緊張

在傳統(tǒng)項(xiàng)目流程中，測試一直是時間分配最少的環(huán)節(jié)，再加上多端測試、Bug驗(yàn)證以及整體回歸，導(dǎo)致測試時間不足的問題很常見也很難避免。

舉例 ：QA在驗(yàn)?zāi)硞€功能時發(fā)現(xiàn)一直有問題，由于RD沒有寫單元測試，較久后才排查出原因，導(dǎo)致QA測試時間更加緊張

4、需求的滿足較慢

在上面已經(jīng)說道，敏捷開發(fā)下的節(jié)奏整體是非常快的。對于RD而言，無論是需要 QA、OP、還是 SRE 等任何一方的需求，滿足速度雖然可能不慢，但還是不能支持敏捷開發(fā)下迭代的速度。

舉例1 ：某個業(yè)務(wù)接口需要自動化測試支持，但 QA 可能需要排期才能完成
舉例2 ：后端服務(wù)上線時可能由于配置缺少等問題發(fā)生 panic，需要 SRE 在 CI 中新增配置檢查，但需要排期才能完成

三、如何解決

在面對以上種種問題下，如果沒有一個完整健全的機(jī)制，是難以輕松應(yīng)對敏捷開發(fā)這種快迭代速度的，交付質(zhì)量也會大打折扣。

所以為了解決這個問題，我們開始運(yùn)用 Devops 思想，基于 CI 來建立一套完整的、覆蓋廣的服務(wù)端自動化，打破不同部門之間的壁壘，適應(yīng)快速迭代，滿足質(zhì)量要求。

四、我們的實(shí)踐

1、設(shè)計方案

(1) 輕量化設(shè)計

在設(shè)計之初，最主要的目標(biāo)就是輕量化 。輕量絕不代表著不完整或不成熟，反而是省去了所有的細(xì)枝末節(jié)后，用一種更少的成本，更快速的滿足實(shí)現(xiàn)了我們的需求。 所以在整個設(shè)計中，都會貫穿輕量化的思想。

• 僅依賴 Gitlab 現(xiàn)有的 Runner 機(jī)器作為服務(wù)器，沒有再使用額外的機(jī)器資源
• 沒有使用額外的后臺管理系統(tǒng)，直接選擇了 Gitlab Repository 作為托管服務(wù)，接口文檔分別放置在 Gitlab倉庫的 /apidoc.md 和 Wiki 中
• 雖然使用了第三方緩存?zhèn)}庫，但為了速度足夠快，我們希望可以不使用50MB以上的工具。其實(shí)到目前為止，大部分使用的工具都在10MB以下。

(2) 多項(xiàng)目共用

在微服務(wù)架構(gòu)下，一套代碼被劃分到多個代碼庫中，多個代碼庫下都有自己的 CI 代碼，一旦 CI 中任意一個流程有變動，那么所有項(xiàng)目都需要配合修改，造成的整體聯(lián)動調(diào)整過大。

為了解決這個問題，采用了如下多項(xiàng)目共用的設(shè)計。在這個設(shè)計中，不需要再把 CI 運(yùn)行邏輯寫在 gitlab-ci.yml 文件中了，而是寫在 CommonCI 這樣的倉庫中，并由 start.sh 腳本啟動。

(3) 插拔式任務(wù)

基于插拔式擴(kuò)展的思想，所有的任務(wù)也都是可插拔、易擴(kuò)展且完全可控的，還可以實(shí)現(xiàn)多任務(wù)的編排。

(4) 第三方緩存

在運(yùn)行過程中，雖然 gitlab CI 提供了如 cache 和 artifacts 這樣的中間產(chǎn)物功能，但它們會有很多限制，有時候可能無法良好滿足。所以會設(shè)計自己的第三方 Cache 庫，用來存放已經(jīng)編譯好的二進(jìn)制文件，加快 CI 的執(zhí)行時間。

2、技術(shù)和思想

(1) 使用到的技術(shù)

• Gitlab 技術(shù)棧 ：基于 gitlab CI 和 gitlab API 實(shí)現(xiàn)流水線的自動工作和相關(guān)托管功能
• Shell 編程 ：為了實(shí)現(xiàn)流水線中不同任務(wù)的插拔和編排，需要使用大量的 Shell 編程
• Go 技術(shù)棧 ：對于配置檢查、依賴檢查、接口文檔生成、自動化測試等一系列需要對業(yè)務(wù)代碼處理的工作，都依賴 Go 技術(shù)棧
• 容器技術(shù)棧 ：雖然目前僅第三方緩存庫基于 Docker 對各種源碼包編譯實(shí)現(xiàn)，不過為了方便支持日后的服務(wù)容器化管理，容器技術(shù)棧會在計劃之中

(2) 使用到的思想

• Devops ：「為什么要做服務(wù)端自動化」「這樣做的意義是什么」「如何去做」等等，它們的背后都是 Devops 思想

3、整體的架構(gòu)

基于 CI 建立的服務(wù)端自動化架構(gòu)如下所示，它一共分為三層 ：

• 代碼倉庫層 ：是代碼倉庫的總稱，包括業(yè)務(wù)和通用倉庫
• Runner 層 ：是 Gitlab 配置的 Runner ，是實(shí)際運(yùn)行 CI 的服務(wù)器
• CI 自動化層 ：是對服務(wù)端自動化的抽象，包括了一系列的插拔式任務(wù)，它們共同構(gòu)成了整個自動化的流水線。

4、代碼倉庫層

從上圖架構(gòu)中的代碼倉庫層可知，除了業(yè)務(wù)代碼倉庫外，還有通用代碼倉庫，其中最重要的就是我們設(shè)計的 CommonCI 倉庫。CommonCI倉庫是解決多項(xiàng)目 CI 共用的核心實(shí)現(xiàn)，它的目錄結(jié)構(gòu)如下所示。

• /.gitlab ：包括通用方法和不同任務(wù)的 CI 目錄
• /start.sh ：啟動 CI 的腳本。當(dāng)執(zhí)行這個腳本時，會自動執(zhí)行 /.gitlab 目錄下的 *.sh 腳本文件 ，它們就是服務(wù)端自動化中的所有任務(wù)

5、CI 自動化層

(1) 預(yù)安裝

詳情請見源代碼 .gitlab/apidoc_gen.sh

在執(zhí)行 CI 前，可能需要大量的安裝操作，我們都放在了 .gitlab/pre_install.sh 預(yù)安裝腳本中。

(2) 代碼檢查

詳情請見源代碼 .gitlab/check_code.sh

一般情況下，對于代碼檢查工具的使用，不僅僅是為了規(guī)范代碼，更多更強(qiáng)烈的需求是希望它能盡可能的幫助我們檢查出大部分的代碼錯誤。

通過代碼掃描、詞法/語法分析、控制流分析等技術(shù)實(shí)現(xiàn)程序的靜態(tài)分析，甚至還可以針對我們的業(yè)務(wù)做定制化的 Bug 分析。

所以我們在 CI 中添加了 golangci-lint 代碼檢查工具，讓RD可以更加放心的提交代碼。

① 定制化檢查

如以下代碼是在業(yè)務(wù)中比較常見且易犯的錯誤，基于定制化 Bug 分析的這種場景需求，還可以開發(fā)更加輕量的內(nèi)部代碼檢查工具，它可以簡單的分析識別出以下語法錯誤。

// 正確
var logger = logging.For(ctx, "arg1", "value1", "arg2", value2)

// 錯誤
var logger = logging.For(ctx, "arg1", "value1", "arg2")

(3) 配置檢查

在開發(fā)階段，在測試環(huán)境添加了某個（Kafka、Redis、Server）的配置后，可能由于疏忽在線上忘記了添加對應(yīng)的配置，導(dǎo)致服務(wù)一上線就發(fā)生 panic 或觸發(fā)某個邏輯后產(chǎn)生 panic ，嚴(yán)重可能會影響到業(yè)務(wù)。

為了避免這種情況，基于這種場景，我們基于 Go 開發(fā)了一個輕量的配置檢查工具，并通過 Shell 集成至 CI 中，它可以基于測試和線上兩種環(huán)境的配置內(nèi)容，做出相應(yīng)的 diff ，幫助我們檢查是否缺少相應(yīng)的線上配置。

(4) 依賴檢查

在微服務(wù)架構(gòu)下，一般每個業(yè)務(wù)至少都會有幾十個代碼庫，對于相似的邏輯，有時候避免不了需要跨項(xiàng)目甚至跨業(yè)務(wù)的復(fù)制粘貼，如果稍加不注意，就很容易出現(xiàn)把A項(xiàng)目的 package 錯誤添加到了B項(xiàng)目的依賴中。

如果你夠幸運(yùn)的話，代碼可能會跑不起來，這時候就會發(fā)現(xiàn)原來是引入了錯誤的依賴，修改后即可避免一次錯誤。如果不幸運(yùn)，代碼可能會運(yùn)行起來，導(dǎo)致上線后可能才會在某個條件下觸發(fā)這個錯誤，進(jìn)而影響業(yè)務(wù)。

為了避免這種情況，基于這種場景，我們基于 Go 開發(fā)了一個輕量的依賴檢查工具，并通過 Shell 集成至 CI 中，它會解析項(xiàng)目的 Godeps.json 文件，從中找出錯誤的依賴。

(5) 單元測試

詳情請見源代碼 .gitlab/unit_test.sh

相信大部分的 RD 都有這樣的經(jīng)歷，開發(fā)了一期大需求，雖然QA也正常測試完成了，但看著幾十個文件、上千行代碼的 diff ，總感覺心里沒底。出現(xiàn)這個問題的大部分原因，是因?yàn)?RD 自己沒有做好單元測試。

由于 RD 的代碼對 QA 來說是透明的，他們根本不知道代碼的邏輯是什么，只能從用戶的使用角度去測試，但用戶的動作是無法枚舉完的，總會有想象不到的地方。

所以為了避免這個問題，也為了降低代碼改動對以前業(yè)務(wù)邏輯的影響，我們在項(xiàng)目代碼中編寫了較大量的單元測試并集成至 CI 中。

(6) 本地構(gòu)建

詳情請見源代碼 .gitlab/local_build.sh

現(xiàn)代DevOps涉及軟件應(yīng)用程序在整個開發(fā)生命周期內(nèi)的持續(xù)集成和持續(xù)部署。所以我們在 CI 中集成了本地構(gòu)建的任務(wù)，它會完成整個項(xiàng)目部署構(gòu)建的過程，包括打包上傳等后續(xù)操作。

(7) 啟動自檢

詳情請見源代碼 .gitlab/health_check.sh

根據(jù)以往經(jīng)驗(yàn)，項(xiàng)目在線上或者測試環(huán)境部署時直接出現(xiàn) panic 的情況是時有發(fā)生的。為了解決這個問題，上面的配置檢查是其中一個方案，但它還遠(yuǎn)遠(yuǎn)不夠，因?yàn)槲覀兊姆?wù)并沒有真正的啟動起來，如果不啟動就無法確定服務(wù)是否真的可以正常運(yùn)行。

所以為了避免這種情況，我們在 CI 中集成了服務(wù)啟動和自檢查的功能。

(8) 接口文檔生成

詳情請見源代碼 .gitlab/apidoc_gen.sh

眾所周知，接口文檔的治理一直是一個開發(fā)流程中非常難真正解決掉的問題，所以也由此催生很多和 Swagger 類似的接口文檔自動生成工具。

不過我們并沒有使用 Swagger ，雖然它足夠應(yīng)對遇到的所有場景，但是它太過龐大，完全不適合我們的業(yè)務(wù)使用。

所以我們用 Go 開發(fā)了一個基于 Model 的 API Mock 工具，它是一個絕對輕量且能滿足業(yè)務(wù)需求的接口文檔生成工具，不但不需要服務(wù)器托管，還節(jié)省了大量成本。

(9) 接口自動化測試

詳情請見源代碼 .gitlab/api_test.sh

雖然我們已經(jīng)有了單元測試，但單元測試只是對某個邏輯中細(xì)小的一個單元進(jìn)行測試，無法確保整個接口層面的正常工作。

所以為了更高一層的服務(wù)穩(wěn)定考慮，我們決定加入自動化測試，它不但可以替代一部分 QA 的工作，而且還可以提高服務(wù)的穩(wěn)定性。

實(shí)現(xiàn)原理是我們創(chuàng)建了一個基于 Go 語言的接口自動化測試倉庫，RD 負(fù)責(zé)編寫相關(guān)的接口測試用例，最后通過 Shell 接入至 CI 中。

(10) 任務(wù)的添加刪除

當(dāng)需要添加新的任務(wù)或刪除任務(wù)時，只需要在 start.sh 腳本中添加或刪除即可。

比如現(xiàn)在需要新增一個自動部署的任務(wù)，先添加 auto_deploy.sh 腳本 ，然后添加到 start.sh 腳本中即可 ，如下所示。

6、項(xiàng)目如何接入

在以往的項(xiàng)目中，當(dāng)接入 CI 時，需要在 .gitlab-ci.yml 文件中寫大量復(fù)雜的代碼邏輯，可維護(hù)性非常差。為了支持多業(yè)務(wù)的快速接入，必須盡可能減小接入成本。

(1) 只需要創(chuàng)建一個配置文件

不同項(xiàng)目接入時，只需要創(chuàng)建一個非常簡單的 .gitlab-ci.yml 文件，然后按照如下模板化的方式配置業(yè)務(wù)方所需要的變量即可。

# this example yml file: https://jihulab.com/WGrape/apimock-example/-/blob/main/.gitlab-ci.yml
image: golang:1.17
variables:
  # variable configuration for [your private gitlab host]
  GITLAB_HOST: ""
  GITLAB_API_TOKEN: ""

  # variable configuration for [your project]
  PROJECT_NAME: "apimock-example"
  PROJECT_ID: 48845

  # variable configuration for [DingDing WebHook]
  DING_KEYWORD: "apimock-example"
  DING_ACCESS_TOKEN: ""
  DING_NOTICE_SWITCH: "off"

  # variable configuration for [check code]
  CHECK_CODE_SWITCH: "on"

  # variable configuration for [unit test]
  UNIT_TEST_TRIGGER_CMD: "cd mock && go test -v . && cd .. && \
                          cd service && go test -v . && cd ..
                         "
  UNIT_TEST_SWITCH: "on"

  # variable configuration for [apidoc generator]
  APIDOC_TRIGGER_CMD: "cd mock && go test -v . && cd .."
  APIDOC_FILE: "apidoc.md"
  APIDOC_SWITCH: "off"

  # variable configuration for [local build]
  LOCAL_BUILD_TRIGGER_CMD: "go mod download && go build -o project && nohup ./project &"
  LOCAL_BUILD_SWITCH: "on"

  # variable configuration for [health check]
  HEALTH_CHECK_TRIGGER_CMD: "curl -X GET 127.0.0.1:8000/ping"
  HEALTH_CHECK_SUCCESS: "ok"
  HEALTH_CHECK_SWITCH: "on"

before_script:
  - echo '====== CIManager Start Running ========='

after_script:
  - echo '====== CIManager Stopped Successfully ========='

stages:
  - CIManager

CIManager:
  stage: CIManager
  script:
    - git clone -b testing https://github.com/wgrape/CIManager.git ; cp -an ./CIManager/. ./ ; rm -rf ./CIManager ; bash start.sh

(2) 自動創(chuàng)建一個配置文件

創(chuàng)建一個配置文件的方式十分簡單方便，但這種方式還是需要相應(yīng)的人工成本。

為了更加低成本的接入，可以使用我們的CLI工具，它基于 read -p 命令和模板替換的思想，通過人機(jī)交互的輸入，可以完成配置文件的自動創(chuàng)建。

(3) 配置文件的構(gòu)成

從上面的配置文件中可以發(fā)現(xiàn)，它主要由 image 、variables 、before_script 、after_script 、stages 這5個部分構(gòu)成。

• image ：指定一個鏡像
• stages ：定義了 uniteci 這唯一的一個 Stage
• before_script ：在 UniteCI Stage 執(zhí)行前需要執(zhí)行的命令
• after_script ：在 UniteCI Stage 執(zhí)行后需要執(zhí)行的命令
• variables ：整個配置的核心，它定義了在 UniteCI Stage 中所有需要的變量

(4) 配置文件的特點(diǎn)

它不同于傳統(tǒng)配置內(nèi)容主要體現(xiàn)在以下幾個方面。

• 只有一個Stage
• 主要是基于變量驅(qū)動的方式
• 極簡的配置設(shè)計，降低了編寫和接入的門檻，提高可維護(hù)性

7、緩存帶來的性能提升

一切的設(shè)計都是有原因的！之所以設(shè)計中使用第三方緩存，是因?yàn)樵谠缙谡麄€ CI 運(yùn)行過程中，大量的耗時都在 golangci-lint 工具的下載和編譯上面，正常耗時都在5分鐘~10分鐘，有時甚至直接掛起到幾十分鐘以上，嚴(yán)重影響正常使用。

在嘗試了artifacts和cache方案無法解決時，決定開始使用第三方緩存，我們把下載編譯好的 golangci-lint 工具放在了第三方緩存庫中，這樣每次直接下載這個編譯后的二進(jìn)制文件即可。

后期使用了緩存服務(wù)后，幾乎每次運(yùn)行整個 CI 時，都可以在1分鐘內(nèi)即可完成，速度提升了足足5倍以上！

五、我們的目標(biāo)

在經(jīng)過我們的實(shí)踐后，最終確立了最終要實(shí)現(xiàn)的目標(biāo) ：保證服務(wù)穩(wěn)定且高效的迭代

1、穩(wěn)定

在整個項(xiàng)目過程中，特別是上線流程中，不出現(xiàn)各種低級錯誤導(dǎo)致的部署失敗問題，比如以下情況

• 缺少某個服務(wù)配置，導(dǎo)致panic
• 資源未初始化導(dǎo)致的panic，如map未初始化
• 代碼在修改時影響到了其他的邏輯，導(dǎo)致其他地方出現(xiàn)bug
• 代碼有低級錯誤，但是沒有自測，導(dǎo)致服務(wù)部署時根本無法部署成功

2、高效

在整個項(xiàng)目過程中，特別是開發(fā)聯(lián)調(diào)和測試跟進(jìn)流程中，盡可能少出現(xiàn)低效率或工作進(jìn)度阻塞的問題，比如以下情況

• 提測的項(xiàng)目根本無法達(dá)到提測標(biāo)準(zhǔn)，測試工作嚴(yán)重阻塞
• 開發(fā)過程中由于接口文檔等問題，導(dǎo)致前后端工作效率都受到較大影響

六、回顧和總結(jié)

閱讀至此，本文已經(jīng)臨近結(jié)束了。下面我們再來回顧下主要內(nèi)容 ：

1、在敏捷開發(fā)的快速迭代下，我們必須選擇一種合適的服務(wù)端自動化方案，來提高整個開發(fā)周期的速度、質(zhì)量、和流程規(guī)范化。

2、正是基于這個背景，我們才運(yùn)用 Devops 思想，基于 CI 建立了一套完整的、覆蓋廣的服務(wù)端自動化。

3、在設(shè)計的過程中，我們的目標(biāo)是更加的輕量、可擴(kuò)展和低接入成本，方便隨時隨地快速迭代。

4、在實(shí)踐的過程中，我們遇到了如多項(xiàng)目共用、執(zhí)行速度慢等諸多問題并逐一解決。

言而總之，本文從原因到方案，為大家分享了一個比較全面的《基于CI的服務(wù)端自動化》解決方案，希望對大家有所幫助。不過還有一點(diǎn)必須要清楚的是，我們做這個東西不是為了做而做的，而是有切實(shí)的背景需求。這樣即使在快節(jié)奏的迭代下，它也可以為整個開發(fā)流程提高效率和質(zhì)量。