前言
大家好，我是老馬。
“大不了就進廠打螺絲”，這大概是很多人的自嘲，或者是無奈的退路。
我們通常用“打螺絲”來指代一些簡單、重複、機械繁瑣的工作。
眾所周知，一件事物的複雜度是固定的，任何一個零件的加工都需要很多步驟。
那麼，如何讓其變得簡單固定呢？
工廠中的流水線
流水線是工業時代非常偉大的發明。
本質上是對一個複雜的流程進行拆解，改為標準化-簡單化-可度量-可規模化的一個流水線步驟。
好處是工人的門檻降低了很多，每個人只需要專注處理其中的一個小步驟，越簡單，越容易上手；越簡單，也不容易出錯。
當然，每一道工序是否合格，都可以在後續加一道 QA 檢測，驗證是否合格。
這種模式非常適合規模化的生產，可以隨著投入人數的增加，效率大幅度提升，及時響應市場的需求。
缺點
甘蔗不能兩頭甜，流水線模式的缺點也是有的。
流水線的基礎設施要求比較高，前期需要經過長期的規劃+建設，投資成本比較高。
且一旦建成，工業上想隨意修改的成本也會相對較高。
對工人而言，因為工作相對簡單，很容易厭倦和缺乏工作激情。
軟體中的流水線
工業的發展要比軟體早得多，所以有很多值得學習的地方。
1970 年，瀑布式開發模型由溫斯頓·羅伊斯提出，將軟體生命週期劃分為制定計劃、需求分析、軟體設計、程式編寫、軟體測試和執行維護等六個基本活動，規定了它們自上而下、相互銜接的固定次序。
1994 年，Grady Booch 提出持續整合。
看的出來，其實也沒有多少年。大部分公司，還是停留在瀑布開發模式中。
為什麼能提效？
個人理解，最主要的是 CI/CD 讓我們在協作時，可以讓程式碼保持是最新的。
每一個節點，可以新增嚴格的 QA 檢測，比如程式碼是否合併了最新的分支，sonar 掃描質量是否過關，單元測試覆蓋率是否滿足，迴歸用力地透過率是否滿足要求，介面文件自動更新等等。
這樣可以部分功能的提測，讓測試先介入進來。
測試不透過，可以打回讓開發改進最佳化。
因為是持續部署，所以運維這一步已經提前介入了，而不用等到最後交付的時候。
編碼、構建、測試、部署、監控和反饋，有些步驟的自動化減少了人工的干預，更加實時，而且錯誤率也更低。
如何搭建流水線呢？
說的挺好的，令人有些心動！
那麼，哪裡可以買到呢？（劃掉）怎麼自己搭建呢？
技術選型
流水線涉及到的點還是比較多的，真正轉型是一個比較漫長的過程，可以逐步改進。
下面羅列一些老馬比較看好的技術選型：
1. 版本控制系統 (VCS)
- Git：Git 是最常用的版本控制工具，幾乎所有流水線都會與 Git 整合。推薦使用 GitHub、GitLab、Bitbucket 等託管平臺，或者自己搭建 Git 伺服器。
Gitlab 有可以本地部署的版本，大多數中小型公司的不二選擇。
2. 持續整合工具 (CI)
-
Jenkins：Jenkins 是一個非常流行的開源 CI/CD 工具，具有豐富的外掛支援，能夠與 Git 整合，實現自動化構建、測試等功能。
-
GitLab CI/CD：如果你使用 GitLab，它自帶 CI/CD 功能，配置較為簡便，適合中小型專案。
Jenkins 到目前為止還是技術的主流。
3. 構建工具
-
Maven / Gradle（Java）：如果是 Java 專案，Maven 和 Gradle 是常見的構建工具，能夠處理依賴管理和專案構建。
-
npm / yarn（Node.js）：對於 Node.js 專案，npm 和 yarn 是常見的包管理工具，支援構建、測試等。
-
Makefile：對於 C/C++ 專案，Makefile 是經典的構建工具。
老馬是 java 開發，平時 maven 用的最多；前端小夥伴對於 npm 應該不會陌生。
4. 程式碼質量和測試工具
-
SonarQube：一個開源的程式碼質量檢查工具，支援多種語言，能夠檢測程式碼的潛在問題、漏洞、重複程式碼等。
-
JUnit / TestNG / Mocha / Jest：根據不同的開發語言，選擇合適的單元測試框架。
-
Selenium：用於 Web 應用的自動化測試，可以整合到 CI 流水線中。
-
Linting 和格式化工具（如 ESLint、Prettier）：確保程式碼風格統一，減少人工檢查的負擔。
單元測試還是推薦大家寫一寫，當然相對較長的業務鏈，還是需要歸回用例才更有價值。
SonarQube 是一個非常好用的 QA 工具，直接部署即可。
5. 容器化和虛擬化
-
Docker：容器化是現代軟體開發的趨勢，Docker 能夠保證環境一致性，並簡化部署。將應用和其依賴打包成映象，使得在開發、測試、生產環境中都能得到一致的體驗。
-
Kubernetes（可選）：如果你的專案需要部署到叢集或雲環境，可以考慮使用 Kubernetes 管理容器。雖然 Kubernetes 本身較為複雜，但它能夠解決微服務架構中容器編排和服務發現等問題。
容器化這一塊老馬一直在使用，但是實際參與建設的並不多。
不過現在很多公司的 docker 容器化還是挺成熟的，用起來也確實方便快捷。
6. 部署工具
-
Ansible：一個簡單的自動化部署工具，適合管理伺服器的配置和部署任務。
-
Terraform：用於管理基礎設施的開源工具，適合部署到雲平臺。
-
Helm：如果使用 Kubernetes，可以使用 Helm 來簡化 Kubernetes 應用的部署和管理。
部署工具一般推薦自建，或者二開。
核心能力就是 ssh 到指定機器，然後排程執行對應的指令碼。
自建的好處是，後續可以更加靈活的定義巡檢作業+監控報警自愈的流程打通。
7. 監控與日誌管理
-
Prometheus + Grafana：監控工具，Prometheus 收集監控資料，Grafana 用於展示資料，適合在生產環境中使用。
-
ELK Stack（Elasticsearch, Logstash, Kibana）：用於日誌收集、儲存和視覺化，幫助開發和運維人員快速定位問題。
-
CAT：CAT 作為服務端專案基礎元件，提供了 Java, C/C++, Node.js, Python, Go 等多語言客戶端，已經在美團點評的基礎架構中介軟體框架（MVC框架，RPC框架，資料庫框架，快取框架等，訊息佇列，配置系統等）深度整合，為美團點評各業務線提供系統豐富的效能指標、健康狀況、實時告警等。
-
SQL：SQL 這一塊主要是一些業務的處理，目前市面上看起來沒有特別好的，主要是自研。主要就是 SQL 的分散式定時排程。
監控報警是很重要的一個環節，也是老馬最近一直在重點學習的內容。
小結
後續老馬準備專門用一系列專題，實踐搭建一下流水線+DevOps 平臺。
對於中小公司，採用這些工具既能夠保證高效的開發流程，又能夠透過自動化提高程式碼質量和交付速度。
當然，流水線的實際搭建+推廣+使用確實會有很多阻力，但是收益也是巨大的。
分工提升效率，協作促進繁榮。
希望本文對你有所幫助，如果喜歡，歡迎點贊收藏轉發一波。
我是老馬，期待與你的下次相遇。
隨筆
從千萬粉絲“何同學”抄襲開源專案說起，為何純技術死路一條？
資料來源的統一與拆分
監控報警系統的指標、規則與執行閉環
我們的系統應該配置哪些監控報警項？
監控報警系統如何實現自監控?
java 老矣，尚能飯否？
一騎紅塵妃子笑，無人知是荔枝來!
張居正的考成法，對我們有何參考價值？
mongodb/redis/neo4j 如何自己打造一個 web 資料庫視覺化客戶端？
DevOps 平臺越發展，開發運維越快失業？
開源如何健康長久的發展
為什麼會有流水線？
既然選擇了遠方 便只顧風雨兼程
銀行是如何掙錢的？