Bamboo DevOps 工程師

CI/CD 中的遊俠

近些年，因為敏捷項目管理的發展，DevOps 工程師的角色也逐漸被市場所接受。

客觀講，當前市場上很多頂著DevOps 工程師名頭的工程師，並不具備獨立設計DevOps 場景的能力。更多的只是傳統運維轉型過來，充其量是換了一些平台和工具，做著與以往類似的事情。其中很多人，並沒有系統學習過DevOps，他們只專注於自動化的實現。

在這裡，我們就不去拓展DevOps 的知識了。

我也知道對於很多DevOps 工程師來說，都更擅長Jenkins，但一家企業裡並不僅僅只有自動化流水線，還有需求管理、缺陷管理、用例管理這些研發管理相關的場景。照顧到所有角色視角，而非只憑個人喜好，才是DevOps 工程師正確的價值觀。本章節中，我們只說一說DevOps 工程師在Bamboo 中的思路。

如果說系統管理員在Bamboo 中是上帝視角，那麼DevOps 工程師就是Bamboo CI/CD 中的遊俠。

系統管理員更關注系統層面的配置和各第三方服務的對接，可以更前瞻性的在搭建初期就能夠做好服務團隊協作的準備。DevOps 工程師則是與團隊中的各角色直接面對面交流，實實在在解決協作痛點，甚至是對團隊高效協作提出建設性的意見和方案。所以如果該角色對整套軟件研發生命週期沒有足夠經驗積累的話，就很難理解各環節上的痛點，更無法主動發現並打通協作中的不暢。

我們也知道，具備這樣萬金油能力的人在中國企業中並不多見。一方面，很多民營企業並不能認識到技能廣度的重要性，只是一味追求單一技能的深度，從而使得這樣的工程師被企業低估。另一方面，有一些企業本身就不清楚自己需要什麼，只是人云亦云，照貓畫虎招聘了一個工程師，有時候還許以一些更好聽的職位。不管如何，工具人學堂的顧問通常會跟客戶的運維支持工程師協作幾天，再給對方一些場景建議和實操培訓。

部署任務的設計

部署腳本的構建任務

由於微服務架構的興起，交付工作已經不再局限於一體化應用的安裝部署和中間件的維護，而是會衍生到應用的部署設計工作中。交付工程師不再是最後環節的被動接收者，而是成為產品的設計者之一。

無論是部署時需要用到的檢查腳本，還是部署的工具，各服務間的架構設計，又或者是部署用的模板，都將在應用設計之初，就開始進行規劃，這其中的代碼也可以像開發工程師一樣維護在代碼倉庫，也會進行單元測試或集成測試，經過測試環境的驗證，最終跟隨產品版本一起聯合發布。

我也見過一些雲原生團隊，把部署工作本身打包構建成一個容器鏡像，也有版本迭代發布，就像一個產品安裝器一樣管理。

部署環境的配置

無論是何種原因，工具人學堂的顧問都不會推薦把環境信息構建到各個服務或者部署腳本中。只要產品的版本不變，那麼就應該使用相同的部署腳本，配上不同的環境信息，搭建出各個環境上的應用實例。

客觀講，完全解偶部署腳本與環境信息，並不是一項簡單的工作。這就需要上述中我們提到的，工程師必須十分了解產品架構，而躬身入局，直接參與設計，無疑是一個“捷徑”。

部署腳本的渲染

雖然Bamboo 設計了環境實例，並且都支持各自自定義環境變量，但這並不能滿足豐富多樣的實際場景。在定義好的自動化任務中，環境變量的傳遞也不是那麼的隨心所欲，為此，你就得花些心思設計一些實用的小工具來解決這些問題。

但不管如何，花費的精力都是值得的。在一個團隊中，這樣的工作具有極高的複用價值。最重要的是，部署腳本與變量參數解偶，將極大程度的簡化日後的維護成本，也把敏感信息成功的掩藏了起來。

以下這個示例，就是把一些變量提取出來，把配置文件演變成模板，在環境上部署的那一刻，把變量通過一些方式進行替換，從而達到一份模板，在不同環境產生不同配置文件的效果。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ bamboo_tman_app_name }}
  labels:
    app: {{ bamboo_tman_app_name }}
spec:
  replicas: {{ bamboo_tman_app_replica }}
  selector:
    matchLabels:
      app: {{ bamboo_tman_app_name }}
  template:
    metadata:
      labels:
        app: {{ bamboo_tman_app_name }}
    spec:
      containers:
      - name: {{ bamboo_tman_app_name }}
        image: {{ bamboo_tman_app_image }}:{{ bamboo_tman_app_version }}
        ports:
        - containerPort: {{ bamboo_tman_app_port }}

對構建任務的支持

構建任務的環境準備

作為一個DevOps 工程師，不僅僅是關注部署監控，還需要對其他角色的工作進行支持。設計構建任務模板，本應也在其職責範圍之內。

除了本章節提到的部署腳本本身的構建任務，還建議了解各開發技術棧的構建任務。對於開發、測試所關注的構建類項目，在後面的章節我們再講。

此處，我想提到的是另一個方面—— 構建環境

不同技術棧的構建方法和所需依賴都是不同的，如果是直接在代理主機上執行，需要考慮版本和依賴的衝突問題。如果採用所有任務都使用各自容器環境，那就需要提前打包好任務環境鏡像供執行時使用。

構建過程中的第三方對接

有不少企業比較注重安全掃描，因此會要求接入第三方的安全工具，很多時候，開發、測試工程師並不了解這些平台或工具，往往這方面的對接研究工作就交到DevOps 工程師的手上。

其他比如跟項目管理、缺陷管理、測試用例管理、代碼倉庫、製品倉庫這些常規平台的集成，也可能會因為項目不同，大家使用的第三方也不同。插件市場中也可以嘗試搜索相關工具關鍵詞。

構建打包的基礎鏡像

值得一提的是，如果服務最後採用容器構建，那麼建議所有的基礎鏡像也由DevOps 工程師統一整理，這與編譯構建中使用內網倉庫中指定版本的依賴同樣重要。