建站
咨詢
售后
建站咨詢
新聞中心
一、寫在前面
1、開發(fā)模式的演進(jìn)
(1) 傳統(tǒng)的開發(fā)模式
在傳統(tǒng)的開發(fā)模式下，開發(fā)、運(yùn)維、物理機(jī)三者之間的關(guān)系是非常緊密的。當(dāng)開發(fā)完成項(xiàng)目后，運(yùn)維會(huì)負(fù)責(zé)把項(xiàng)目部署到一臺(tái)物理機(jī)上，由這臺(tái)物理機(jī)向外提供服務(wù)。
在常山等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強(qiáng)發(fā)展的系統(tǒng)性、市場(chǎng)前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務(wù)理念，為客戶提供網(wǎng)站制作、網(wǎng)站設(shè)計(jì) 網(wǎng)站設(shè)計(jì)制作按需網(wǎng)站設(shè)計(jì),公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),品牌網(wǎng)站建設(shè),全網(wǎng)整合營銷推廣,外貿(mào)網(wǎng)站建設(shè),常山網(wǎng)站建設(shè)費(fèi)用合理。
由于服務(wù)和物理機(jī)關(guān)系緊密，導(dǎo)致服務(wù)非常依賴于物理機(jī)的環(huán)境。一旦需要調(diào)換物理機(jī)器，運(yùn)維同事又需要在另一臺(tái)物理機(jī)上安裝服務(wù)依賴的環(huán)境，經(jīng)過一頓折騰后，才能完成服務(wù)的部署。
(2) 容器的顛覆革命
為了解決這個(gè)問題，出現(xiàn)了一種名為虛擬機(jī)的操作系統(tǒng)虛擬化產(chǎn)品。不過還發(fā)展沒有太久，就已經(jīng)被一種更輕量級(jí)的操作系統(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ā)把一個(gè)產(chǎn)品交付過程拆分為了多個(gè)小周期，創(chuàng)新性的通過不斷重復(fù)迭代的方式，實(shí)現(xiàn)產(chǎn)品的逐步改進(jìn)和提前交付。從此改變了以往瀑布流模式下的大周期開發(fā)問題，可以提前了解市場(chǎng)需求，規(guī)避風(fēng)險(xiǎn)。
(4) Devops文化運(yùn)動(dòng)
正是在基于容器、敏捷開發(fā)、CI/CD 等各種前瞻技術(shù)思想的發(fā)展下，催生了一場(chǎng)名為 Devops 的文化運(yùn)動(dòng)。在這場(chǎng)文化運(yùn)動(dòng)中，更加強(qiáng)調(diào)加強(qiáng)開發(fā)、測(cè)試、運(yùn)維之間的溝通?，F(xiàn)在已經(jīng)越來越多的公司或團(tuán)隊(duì)開始重視和投入到 Devops 的建設(shè)中，基于 CI/CD 構(gòu)建服務(wù)端的自動(dòng)化，讓整個(gè)開發(fā)模式高效高質(zhì)量的同時(shí)，也更加流程化、規(guī)范化。
2、演進(jìn)過程中的特點(diǎn)
從上可以發(fā)現(xiàn)，隨著技術(shù)發(fā)展，RD 與測(cè)試、運(yùn)維之間的不再是涇渭分明的工作線，反而他們之間的關(guān)系愈加緊密，RD 的整個(gè)開發(fā)模式也開始向自動(dòng)化方向演進(jìn)。
3、為什么要寫這篇文章
在目前的實(shí)際工作中，遇到了一系列影響效率和質(zhì)量的問題。雖然目前有現(xiàn)成的 CI/CD 機(jī)制可以使用，但它的接入成本較高且不易擴(kuò)展。
所以開始嘗試運(yùn)用 Devops 思想并結(jié)合 CI/CD 技術(shù)，創(chuàng)建一個(gè)基于CI的服務(wù)端自動(dòng)化，把項(xiàng)目的開發(fā)、單測(cè)、集測(cè)、部署、檢測(cè)、監(jiān)控等整個(gè)完整的項(xiàng)目流程，都閉環(huán)集成至這個(gè)自動(dòng)化中，實(shí)現(xiàn)更加快速高效高質(zhì)量地交付產(chǎn)品。
經(jīng)過一段時(shí)間的實(shí)踐，效果很好，驗(yàn)證了想法的正確性，故總結(jié)和分享此文章，為大家提供思路與經(jīng)驗(yàn)。
4、這篇文章主要寫了什么
本文會(huì)以 CI/CD 技術(shù)為核心，重點(diǎn)介紹它能為我們帶來什么，我們?yōu)槭裁匆O(shè)計(jì)自己的CI服務(wù)端自動(dòng)化，以及如何設(shè)計(jì)。
5、閱讀文章前的注意內(nèi)容
- CI/CD 這項(xiàng)技術(shù)，下文中會(huì)簡稱為 CI
- 文章內(nèi)容如果出現(xiàn)錯(cuò)誤理解、病句、錯(cuò)別字等，請(qǐng)見諒并歡迎大家的指出
二、問題現(xiàn)狀
1、項(xiàng)目迭代速度快
在瀑布流開發(fā)模式下，一個(gè)項(xiàng)目的周期是足夠長的，一般有充足的時(shí)間來完成整個(gè)項(xiàng)目流程。但在敏捷開發(fā)模式下，開發(fā)內(nèi)容的縮減，伴隨而來的也是需求、測(cè)試等環(huán)節(jié)時(shí)間的縮減，導(dǎo)致迭代速度也越來越快。
舉例 ：今天需要開發(fā)一個(gè)功能，但可能不經(jīng)過測(cè)試，產(chǎn)品驗(yàn)收后就可以上線。
2、第三方工具太重
市面上流行的各種第三方工具大都非常重，功能繁多，依賴復(fù)雜，甚至還都會(huì)附帶一個(gè)后臺(tái)管理系統(tǒng)。導(dǎo)致很多時(shí)候我們只需要某個(gè)工具10%的功能，但不得不接受它90%附加的功能，這類重型工具只適合穩(wěn)定發(fā)展的項(xiàng)目。
對(duì)于快速迭代的項(xiàng)目，需要的是輕量、輕量、還是輕量！
舉例 ：接口文檔自動(dòng)生成工具中，大部分都需要私有服務(wù)器部署而且會(huì)附有各種管理系統(tǒng)。
3、測(cè)試的時(shí)間緊張
在傳統(tǒng)項(xiàng)目流程中，測(cè)試一直是時(shí)間分配最少的環(huán)節(jié)，再加上多端測(cè)試、Bug驗(yàn)證以及整體回歸，導(dǎo)致測(cè)試時(shí)間不足的問題很常見也很難避免。
舉例 ：QA在驗(yàn)?zāi)硞€(gè)功能時(shí)發(fā)現(xiàn)一直有問題，由于RD沒有寫單元測(cè)試，較久后才排查出原因，導(dǎo)致QA測(cè)試時(shí)間更加緊張
4、需求的滿足較慢
在上面已經(jīng)說道，敏捷開發(fā)下的節(jié)奏整體是非?？斓?。對(duì)于RD而言，無論是需要 QA、OP、還是 SRE 等任何一方的需求，滿足速度雖然可能不慢，但還是不能支持敏捷開發(fā)下迭代的速度。
舉例1 ：某個(gè)業(yè)務(wù)接口需要自動(dòng)化測(cè)試支持，但 QA 可能需要排期才能完成
舉例2 ：后端服務(wù)上線時(shí)可能由于配置缺少等問題發(fā)生 panic，需要 SRE 在 CI 中新增配置檢查，但需要排期才能完成
三、如何解決
在面對(duì)以上種種問題下，如果沒有一個(gè)完整健全的機(jī)制，是難以輕松應(yīng)對(duì)敏捷開發(fā)這種快迭代速度的，交付質(zhì)量也會(huì)大打折扣。
所以為了解決這個(gè)問題，我們開始運(yùn)用 Devops 思想，基于 CI 來建立一套完整的、覆蓋廣的服務(wù)端自動(dòng)化，打破不同部門之間的壁壘，適應(yīng)快速迭代，滿足質(zhì)量要求。
四、我們的實(shí)踐
1、設(shè)計(jì)方案
(1) 輕量化設(shè)計(jì)
在設(shè)計(jì)之初，最主要的目標(biāo)就是輕量化 。輕量絕不代表著不完整或不成熟，反而是省去了所有的細(xì)枝末節(jié)后，用一種更少的成本，更快速的滿足實(shí)現(xiàn)了我們的需求。 所以在整個(gè)設(shè)計(jì)中，都會(huì)貫穿輕量化的思想。
- 僅依賴 Gitlab 現(xiàn)有的 Runner 機(jī)器作為服務(wù)器，沒有再使用額外的機(jī)器資源
- 沒有使用額外的后臺(tái)管理系統(tǒng)，直接選擇了 Gitlab Repository 作為托管服務(wù)，接口文檔分別放置在 Gitlab倉庫的 /apidoc.md 和 Wiki 中
- 雖然使用了第三方緩存?zhèn)}庫，但為了速度足夠快，我們希望可以不使用50MB以上的工具。其實(shí)到目前為止，大部分使用的工具都在10MB以下。
(2) 多項(xiàng)目共用
在微服務(wù)架構(gòu)下，一套代碼被劃分到多個(gè)代碼庫中，多個(gè)代碼庫下都有自己的 CI 代碼，一旦 CI 中任意一個(gè)流程有變動(dòng)，那么所有項(xiàng)目都需要配合修改，造成的整體聯(lián)動(dòng)調(diào)整過大。
為了解決這個(gè)問題，采用了如下多項(xiàng)目共用的設(shè)計(jì)。在這個(gè)設(shè)計(jì)中，不需要再把 CI 運(yùn)行邏輯寫在 gitlab-ci.yml 文件中了，而是寫在 CommonCI 這樣的倉庫中，并由 start.sh 腳本啟動(dòng)。
(3) 插拔式任務(wù)
基于插拔式擴(kuò)展的思想，所有的任務(wù)也都是可插拔、易擴(kuò)展且完全可控的，還可以實(shí)現(xiàn)多任務(wù)的編排。
(4) 第三方緩存
在運(yùn)行過程中，雖然 gitlab CI 提供了如 cache 和 artifacts 這樣的中間產(chǎn)物功能，但它們會(huì)有很多限制，有時(shí)候可能無法良好滿足。所以會(huì)設(shè)計(jì)自己的第三方 Cache 庫，用來存放已經(jīng)編譯好的二進(jìn)制文件，加快 CI 的執(zhí)行時(shí)間。
2、技術(shù)和思想
(1) 使用到的技術(shù)
- Gitlab 技術(shù)棧 ：基于 gitlab CI 和 gitlab API 實(shí)現(xiàn)流水線的自動(dòng)工作和相關(guān)托管功能
- Shell 編程 ：為了實(shí)現(xiàn)流水線中不同任務(wù)的插拔和編排，需要使用大量的 Shell 編程
- Go 技術(shù)棧 ：對(duì)于配置檢查、依賴檢查、接口文檔生成、自動(dòng)化測(cè)試等一系列需要對(duì)業(yè)務(wù)代碼處理的工作，都依賴 Go 技術(shù)棧
- 容器技術(shù)棧 ：雖然目前僅第三方緩存庫基于 Docker 對(duì)各種源碼包編譯實(shí)現(xiàn)，不過為了方便支持日后的服務(wù)容器化管理，容器技術(shù)棧會(huì)在計(jì)劃之中
(2) 使用到的思想
- Devops ：「為什么要做服務(wù)端自動(dòng)化」「這樣做的意義是什么」「如何去做」等等，它們的背后都是 Devops 思想
3、整體的架構(gòu)
基于 CI 建立的服務(wù)端自動(dòng)化架構(gòu)如下所示，它一共分為三層 ：
- 代碼倉庫層 ：是代碼倉庫的總稱，包括業(yè)務(wù)和通用倉庫
- Runner 層 ：是 Gitlab 配置的 Runner ，是實(shí)際運(yùn)行 CI 的服務(wù)器
- CI 自動(dòng)化層 ：是對(duì)服務(wù)端自動(dòng)化的抽象，包括了一系列的插拔式任務(wù)，它們共同構(gòu)成了整個(gè)自動(dòng)化的流水線。
4、代碼倉庫層
從上圖架構(gòu)中的代碼倉庫層可知，除了業(yè)務(wù)代碼倉庫外，還有通用代碼倉庫，其中最重要的就是我們?cè)O(shè)計(jì)的 CommonCI 倉庫。CommonCI倉庫是解決多項(xiàng)目 CI 共用的核心實(shí)現(xiàn)，它的目錄結(jié)構(gòu)如下所示。
- /.gitlab ：包括通用方法和不同任務(wù)的 CI 目錄
- /start.sh ：啟動(dòng) CI 的腳本。當(dāng)執(zhí)行這個(gè)腳本時(shí)，會(huì)自動(dòng)執(zhí)行 /.gitlab 目錄下的 *.sh 腳本文件 ，它們就是服務(wù)端自動(dòng)化中的所有任務(wù)
5、CI 自動(dòng)化層
(1) 預(yù)安裝
詳情請(qǐng)見源代碼 .gitlab/apidoc_gen.sh
在執(zhí)行 CI 前，可能需要大量的安裝操作，我們都放在了 .gitlab/pre_install.sh 預(yù)安裝腳本中。
(2) 代碼檢查
詳情請(qǐng)見源代碼 .gitlab/check_code.sh
一般情況下，對(duì)于代碼檢查工具的使用，不僅僅是為了規(guī)范代碼，更多更強(qiáng)烈的需求是希望它能盡可能的幫助我們檢查出大部分的代碼錯(cuò)誤。
通過代碼掃描、詞法/語法分析、控制流分析等技術(shù)實(shí)現(xiàn)程序的靜態(tài)分析，甚至還可以針對(duì)我們的業(yè)務(wù)做定制化的 Bug 分析。
所以我們?cè)?CI 中添加了 golangci-lint 代碼檢查工具，讓RD可以更加放心的提交代碼。
① 定制化檢查
如以下代碼是在業(yè)務(wù)中比較常見且易犯的錯(cuò)誤，基于定制化 Bug 分析的這種場(chǎng)景需求，還可以開發(fā)更加輕量的內(nèi)部代碼檢查工具，它可以簡單的分析識(shí)別出以下語法錯(cuò)誤。
// 正確
var logger = logging.For(ctx, "arg1", "value1", "arg2", value2)
// 錯(cuò)誤
var logger = logging.For(ctx, "arg1", "value1", "arg2")(3) 配置檢查
在開發(fā)階段，在測(cè)試環(huán)境添加了某個(gè)（Kafka、Redis、Server）的配置后，可能由于疏忽在線上忘記了添加對(duì)應(yīng)的配置，導(dǎo)致服務(wù)一上線就發(fā)生 panic 或觸發(fā)某個(gè)邏輯后產(chǎn)生 panic ，嚴(yán)重可能會(huì)影響到業(yè)務(wù)。
為了避免這種情況，基于這種場(chǎng)景，我們基于 Go 開發(fā)了一個(gè)輕量的配置檢查工具，并通過 Shell 集成至 CI 中，它可以基于測(cè)試和線上兩種環(huán)境的配置內(nèi)容，做出相應(yīng)的 diff ，幫助我們檢查是否缺少相應(yīng)的線上配置。
(4) 依賴檢查
在微服務(wù)架構(gòu)下，一般每個(gè)業(yè)務(wù)至少都會(huì)有幾十個(gè)代碼庫，對(duì)于相似的邏輯，有時(shí)候避免不了需要跨項(xiàng)目甚至跨業(yè)務(wù)的復(fù)制粘貼，如果稍加不注意，就很容易出現(xiàn)把A項(xiàng)目的 package 錯(cuò)誤添加到了B項(xiàng)目的依賴中。
如果你夠幸運(yùn)的話，代碼可能會(huì)跑不起來，這時(shí)候就會(huì)發(fā)現(xiàn)原來是引入了錯(cuò)誤的依賴，修改后即可避免一次錯(cuò)誤。如果不幸運(yùn)，代碼可能會(huì)運(yùn)行起來，導(dǎo)致上線后可能才會(huì)在某個(gè)條件下觸發(fā)這個(gè)錯(cuò)誤，進(jìn)而影響業(yè)務(wù)。
為了避免這種情況，基于這種場(chǎng)景，我們基于 Go 開發(fā)了一個(gè)輕量的依賴檢查工具，并通過 Shell 集成至 CI 中，它會(huì)解析項(xiàng)目的 Godeps.json 文件，從中找出錯(cuò)誤的依賴。
(5) 單元測(cè)試
詳情請(qǐng)見源代碼 .gitlab/unit_test.sh
相信大部分的 RD 都有這樣的經(jīng)歷，開發(fā)了一期大需求，雖然QA也正常測(cè)試完成了，但看著幾十個(gè)文件、上千行代碼的 diff ，總感覺心里沒底。出現(xiàn)這個(gè)問題的大部分原因，是因?yàn)?RD 自己沒有做好單元測(cè)試。
由于 RD 的代碼對(duì) QA 來說是透明的，他們根本不知道代碼的邏輯是什么，只能從用戶的使用角度去測(cè)試，但用戶的動(dòng)作是無法枚舉完的，總會(huì)有想象不到的地方。
所以為了避免這個(gè)問題，也為了降低代碼改動(dòng)對(duì)以前業(yè)務(wù)邏輯的影響，我們?cè)陧?xiàng)目代碼中編寫了較大量的單元測(cè)試并集成至 CI 中。
(6) 本地構(gòu)建
詳情請(qǐng)見源代碼 .gitlab/local_build.sh
現(xiàn)代DevOps涉及軟件應(yīng)用程序在整個(gè)開發(fā)生命周期內(nèi)的持續(xù)集成和持續(xù)部署。所以我們?cè)?CI 中集成了本地構(gòu)建的任務(wù)，它會(huì)完成整個(gè)項(xiàng)目部署構(gòu)建的過程，包括打包上傳等后續(xù)操作。
(7) 啟動(dòng)自檢
詳情請(qǐng)見源代碼 .gitlab/health_check.sh
根據(jù)以往經(jīng)驗(yàn)，項(xiàng)目在線上或者測(cè)試環(huán)境部署時(shí)直接出現(xiàn) panic 的情況是時(shí)有發(fā)生的。為了解決這個(gè)問題，上面的配置檢查是其中一個(gè)方案，但它還遠(yuǎn)遠(yuǎn)不夠，因?yàn)槲覀兊姆?wù)并沒有真正的啟動(dòng)起來，如果不啟動(dòng)就無法確定服務(wù)是否真的可以正常運(yùn)行。
所以為了避免這種情況，我們?cè)?CI 中集成了服務(wù)啟動(dòng)和自檢查的功能。
(8) 接口文檔生成
詳情請(qǐng)見源代碼 .gitlab/apidoc_gen.sh
眾所周知，接口文檔的治理一直是一個(gè)開發(fā)流程中非常難真正解決掉的問題，所以也由此催生很多和 Swagger 類似的接口文檔自動(dòng)生成工具。
不過我們并沒有使用 Swagger ，雖然它足夠應(yīng)對(duì)遇到的所有場(chǎng)景，但是它太過龐大，完全不適合我們的業(yè)務(wù)使用。
所以我們用 Go 開發(fā)了一個(gè)基于 Model 的 API Mock 工具，它是一個(gè)絕對(duì)輕量且能滿足業(yè)務(wù)需求的接口文檔生成工具，不但不需要服務(wù)器托管，還節(jié)省了大量成本。
(9) 接口自動(dòng)化測(cè)試
詳情請(qǐng)見源代碼 .gitlab/api_test.sh
雖然我們已經(jīng)有了單元測(cè)試，但單元測(cè)試只是對(duì)某個(gè)邏輯中細(xì)小的一個(gè)單元進(jìn)行測(cè)試，無法確保整個(gè)接口層面的正常工作。
所以為了更高一層的服務(wù)穩(wěn)定考慮，我們決定加入自動(dòng)化測(cè)試，它不但可以替代一部分 QA 的工作，而且還可以提高服務(wù)的穩(wěn)定性。
實(shí)現(xiàn)原理是我們創(chuàng)建了一個(gè)基于 Go 語言的接口自動(dòng)化測(cè)試倉庫，RD 負(fù)責(zé)編寫相關(guān)的接口測(cè)試用例，最后通過 Shell 接入至 CI 中。
(10) 任務(wù)的添加刪除
當(dāng)需要添加新的任務(wù)或刪除任務(wù)時(shí)，只需要在 start.sh 腳本中添加或刪除即可。
比如現(xiàn)在需要新增一個(gè)自動(dòng)部署的任務(wù)，先添加 auto_deploy.sh 腳本 ，然后添加到 start.sh 腳本中即可 ，如下所示。
6、項(xiàng)目如何接入
在以往的項(xiàng)目中，當(dāng)接入 CI 時(shí)，需要在 .gitlab-ci.yml 文件中寫大量復(fù)雜的代碼邏輯，可維護(hù)性非常差。為了支持多業(yè)務(wù)的快速接入，必須盡可能減小接入成本。
(1) 只需要?jiǎng)?chuàng)建一個(gè)配置文件
不同項(xiàng)目接入時(shí)，只需要?jiǎng)?chuàng)建一個(gè)非常簡單的 .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) 自動(dòng)創(chuàng)建一個(gè)配置文件
創(chuàng)建一個(gè)配置文件的方式十分簡單方便，但這種方式還是需要相應(yīng)的人工成本。
為了更加低成本的接入，可以使用我們的CLI工具，它基于 read -p 命令和模板替換的思想，通過人機(jī)交互的輸入，可以完成配置文件的自動(dòng)創(chuàng)建。
(3) 配置文件的構(gòu)成
從上面的配置文件中可以發(fā)現(xiàn)，它主要由 image 、variables 、before_script 、after_script 、stages 這5個(gè)部分構(gòu)成。
- image ：指定一個(gè)鏡像
- stages ：定義了 uniteci 這唯一的一個(gè) Stage
- before_script ：在 UniteCI Stage 執(zhí)行前需要執(zhí)行的命令
- after_script ：在 UniteCI Stage 執(zhí)行后需要執(zhí)行的命令
- variables ：整個(gè)配置的核心，它定義了在 UniteCI Stage 中所有需要的變量
(4) 配置文件的特點(diǎn)
它不同于傳統(tǒng)配置內(nèi)容主要體現(xiàn)在以下幾個(gè)方面。
- 只有一個(gè)Stage
- 主要是基于變量驅(qū)動(dòng)的方式
- 極簡的配置設(shè)計(jì)，降低了編寫和接入的門檻，提高可維護(hù)性
7、緩存帶來的性能提升
一切的設(shè)計(jì)都是有原因的！之所以設(shè)計(jì)中使用第三方緩存，是因?yàn)樵谠缙谡麄€(gè) CI 運(yùn)行過程中，大量的耗時(shí)都在 golangci-lint 工具的下載和編譯上面，正常耗時(shí)都在5分鐘~10分鐘，有時(shí)甚至直接掛起到幾十分鐘以上，嚴(yán)重影響正常使用。
在嘗試了artifacts和cache方案無法解決時(shí)，決定開始使用第三方緩存，我們把下載編譯好的 golangci-lint 工具放在了第三方緩存庫中，這樣每次直接下載這個(gè)編譯后的二進(jìn)制文件即可。
后期使用了緩存服務(wù)后，幾乎每次運(yùn)行整個(gè) CI 時(shí)，都可以在1分鐘內(nèi)即可完成，速度提升了足足5倍以上！
五、我們的目標(biāo)
在經(jīng)過我們的實(shí)踐后，最終確立了最終要實(shí)現(xiàn)的目標(biāo) ：保證服務(wù)穩(wěn)定且高效的迭代
1、穩(wěn)定
在整個(gè)項(xiàng)目過程中，特別是上線流程中，不出現(xiàn)各種低級(jí)錯(cuò)誤導(dǎo)致的部署失敗問題，比如以下情況
- 缺少某個(gè)服務(wù)配置，導(dǎo)致panic
- 資源未初始化導(dǎo)致的panic，如map未初始化
- 代碼在修改時(shí)影響到了其他的邏輯，導(dǎo)致其他地方出現(xiàn)bug
- 代碼有低級(jí)錯(cuò)誤，但是沒有自測(cè)，導(dǎo)致服務(wù)部署時(shí)根本無法部署成功
2、高效
在整個(gè)項(xiàng)目過程中，特別是開發(fā)聯(lián)調(diào)和測(cè)試跟進(jìn)流程中，盡可能少出現(xiàn)低效率或工作進(jìn)度阻塞的問題，比如以下情況
- 提測(cè)的項(xiàng)目根本無法達(dá)到提測(cè)標(biāo)準(zhǔn)，測(cè)試工作嚴(yán)重阻塞
- 開發(fā)過程中由于接口文檔等問題，導(dǎo)致前后端工作效率都受到較大影響
六、回顧和總結(jié)
閱讀至此，本文已經(jīng)臨近結(jié)束了。下面我們?cè)賮砘仡櫹轮饕獌?nèi)容 ：
1、在敏捷開發(fā)的快速迭代下，我們必須選擇一種合適的服務(wù)端自動(dòng)化方案，來提高整個(gè)開發(fā)周期的速度、質(zhì)量、和流程規(guī)范化。
2、正是基于這個(gè)背景，我們才運(yùn)用 Devops 思想，基于 CI 建立了一套完整的、覆蓋廣的服務(wù)端自動(dòng)化。
3、在設(shè)計(jì)的過程中，我們的目標(biāo)是更加的輕量、可擴(kuò)展和低接入成本，方便隨時(shí)隨地快速迭代。
4、在實(shí)踐的過程中，我們遇到了如多項(xiàng)目共用、執(zhí)行速度慢等諸多問題并逐一解決。
言而總之，本文從原因到方案，為大家分享了一個(gè)比較全面的《基于CI的服務(wù)端自動(dòng)化》解決方案，希望對(duì)大家有所幫助。不過還有一點(diǎn)必須要清楚的是，我們做這個(gè)東西不是為了做而做的，而是有切實(shí)的背景需求。這樣即使在快節(jié)奏的迭代下，它也可以為整個(gè)開發(fā)流程提高效率和質(zhì)量。
當(dāng)前文章：基于CI的服務(wù)端自動(dòng)化設(shè)計(jì)與實(shí)踐
網(wǎng)站URL：http://m.5511xx.com/article/djejhhj.html
