一個簡單CI/CD流程的思考

  由於公司有兩地研發團隊,在統一CI/CD上難度不亞於兩家公司合併後的新流程創建,並不是不可攻克,簡單描述下心得。html

  首先,代碼管理使用gerrit -> 因其強大的 codereview 功能被選中爲 codebase 的選型,並且,咱們依賴於 gerrit event 觸發流程,取代溝通基本靠喊的簡單粗暴的方式。前端

  關於 gerrit event 介紹,請參考node

  https://gerrit-review.googlesource.com/Documentation/cmd-stream-events.htmlpython

  本來,CI/CD 流程是重度依賴 jenkins 及其插件。但因 jenkins 的排隊處理,及其插件 gerrit-trigger 的 miss 率達到將近 10%(針對本公司 gerrit 提交狀況),致使 CI/CD 流程沒法得到指望中的推廣效果,故拋棄 jenkins 插件,下降 jenkins 使用權重,下降替代 jenkins 的成本 json

  使用 python 開發 gerrit client, 監聽 gerrit event 事件(目前只處理 PatchSet Create & ChangeMerged ) app

監聽 gerrit event:ssh

def run(self):
host = self.config.get("gerrit_host", "example.net")
user = self.config.get("gerrit_user", "engineer")
port = int(self.config.get("gerrit_ssh_port", "29418"))
fkey = self.config.get("gerrit_key_file", None)
etyp = self.config.get("gerrit_event_types", "").split(",")
events = queue.Queue()
listener = StreamEventListener(events, user, host, port, fkey)
listener.set_event_types(etyp)
listener.set_logger(self.logger)
listener.start()
while True:
e = events.get()
handler = GerritStreamEventHandler(e, self.logger, self.config)
handler.start() maven

 

  eg:工具

if "patchset-created" == etype:
taskQueues[project][cs].put(self.event)
taskQueues[project][ut].put(self.event)
elif "change-merged" == etype:
#change-merged,啓動ci構建jobpost

url = 'http://127.0.0.1:9091/citrigger'
param = {"event":event}
header = {"Content-Type": "application/json"}
response = requests.post("http://127.0.0.1:3200/", json=param, headers = header)
log_trigger_fmt = "Trigger ci job on [{}], ref: {}, event created {}, responses :{}"
self.logger.info(log_trigger_fmt(project, ref, etime, response))

此處,經過使用自行開發的EventListner 及 handler,替代 jenkins 中 gerrit trigger的功能,解決了 miss 的問題!

另外,發佈系統做爲前端展現及任務調度的部分,能夠完成數據統計,針對某個提交進行重複構建,記錄發佈歷史,統一公司項目結構進行的技術限制,保證高度統一。

 

  經過 trigger 的轉發及過濾,能夠確保每一次開發的提交在通過submit後獲得構建,構建使用的工具仍是採用了 jenkins (天坑jenkins,之後會丟掉的),經過參數化構建的方式,並依賴於公司內同一類型的項目的構建方式統一 (nodejs, maven, gradle),消息處理,更新模板,建立job, 更新job, 這個部分由一個獨立的服務來維護, 服務與 jenkins 通訊,維護 jenkins 中 job的配置信息。

 

設計思路

  1. 啓用端口監聽 發佈系統 發來的請求:
  • 請求包含4個部分 type Income struct { AppId string json:"app_id" Project string json:"project" TaskId string json:"task_id" Ref string json:"ref" }
  1. 進行如下處理:
  • 根據 AppId, 搜索該項目是否有特殊配置(構建前/後的命令執行),若是有,不執行刷新 job template 的操做,若是沒有, 根據項目類型刷新對應的 job template
  • 根據 AppId, 獲取該項目的 job url,並執行構建操做
  • Job Build 須要的參數 type Param struct { Ref string json:"Ref" TaskId string json:"TaskId" AppId string json:"AppId" Project string json:"project" Module string json:"Module" }
  1. 新增建立job端口,進行如下處理:
  • 接收發布系統的請求: type CreateIncome struct { AppId string json:"app_id" Project string json:"project" Type string json:"type"Module string json:"module" SzOrSh string json:"SzOrSh" }
  • 收到請求後,在 t_app_job 插入記錄便可

 

相關文章
相關標籤/搜索