【我想出門！】關於 devops 的一些思考

2020 年 2 月 25 日
筆記

上半年在做微信文檔的時候，有一些自動化的需求，比如像一鍵發布，git push 發布，自動發布等。後面推動內部運維，做了 devops 的嘗試。以前手工發布會經常遇到環境問題、許可權問題、測試問題，基本上此次都要解說好久，而且大部分都是重複描述，我只能說：我太難了。

整體感覺上來說，在接入 devops 之後，徹底解決了我在開發和客服之間身份徘徊的問題，讓我能夠更加專註到開發中去。

藉由此機會，順便了解下業界關於自動化系統的方案。

常見自動化系統

在日常開發中，遇見兩種比較具有代表性的系統，一個是騰訊內部的藍盾流水線(pipeline)，一個是 github Action(yml) 。

藍盾(左圖): 通過流水線編排的方式，將編譯、測試、自動化部署通過服務的方式來提供，用戶能夠非常直觀的了解到自己實現的流水線是什麼，以及它完成了哪些事情。
github action(右圖): 通過 yml 文件格式，描述當前 action 需要做的任務。整體來說，這種方式對於開發者上手門檻較高，裡面包含了很多開發者陌生的概念，比如 action、job、runner 等。但是，正是由於這些概念，也給 github action 帶來很大的靈活性。

(本人作為一個非專業且業餘的開發者來說，還是挺中意騰訊藍盾這種傻瓜式流水線的模式。

了解一下概念

在自動化系統中，有幾個必備概念需要了解，便於你在後續開發中的應用，CI(Continuous Integration, 持續集成)、CD(Continuous Delivery, 持續交付)、CD(Continuous Deployment, 持續部署)，還有一個 DevOps(自動化運維) 。

CI: 主要完成的事實，保證每次合併到主幹的程式碼都是可用，並且都是經過自動化測試的。比如，A 在 feature-A 開發了一個功能，完畢後，合併到 master，此時通過 PR 觸發自動化 CI，如果 CI 失敗了，則說明 A 的程式碼有毒，需要 review 一遍。
CD(Continuous Delivery, 持續交付): 當多個開發者完成功能開發後，會通過一系列自動化測試，人工測試後，達到一個可發布階段(staging)，最終是通過手動來確定是否發布。
CD(Continuous Deployment, 持續部署)：比持續交付更自動化，最終的發布環節也是自動發布的。這個環節去年做的文檔自動化類似，改了文檔之後，提交程式碼直接上線。

參考下圖，可能更明確些：

最後還有個 DevOps，這個概念就很玄學，可以說 DevOps 是一種自動化理念，通過 CI/CD 的方式來保持測試環境和生產環境的一致性，解決運維和開發之間的溝通問題。這個概念可以參考下圖：

打算做什麼

前段時間在做微信文檔自動化時，devops 其實就已經帶給我了很大的震撼（原來微信以前的運維繫統這麼難用。之後，組內有部分是小程式業務，了解了一下，基本現狀是一切圍繞開發者工具，搞個 Macos 系統 + 微信開發者工具，通過 http 的方式來調用工具提供的腳本命令。這個也是業界大部分自動化系統的做法。

整體來說，只要你搞的自動化系統上有開發者工具，其他的自動化操作都可以完成。不過，細細挖掘會發現，這樣做的成本還是有點高，比如，你原先在一個組裡面做了一個自動化系統，但是，你很難將這個自動化系統再推廣到其他組去（分享能力差，不易復用。

因為和工具那邊隔的很近，有消息工具已經把程式碼上傳的能力放出來，這樣做解決了自動化系統大部分的工作量，點個贊。