從 Bamboo 到極狐GitLab 的遷移指南詳情 - ci,持續集成,devops,gitlab 極狐GitLab 博客

內容來源： https://about.gitlab.com/blog
作者： Abubakar Siddiq Ango

Atlassian 表示，將在 2024 年 2 月，終止對於旗下所有服務器端產品（Server products）的支持。

隨着這個時間節點的逐漸臨近。那些依賴於私有化部署了 Atlassian 服務端產品的用户來説，面臨着抉擇：要麼升級到 Atliassian 的數據中心或者雲產品來繼續使用 Atliasian 的產品，要麼尋找替代產品。

Bamboo 就是受此影響的其中一款產品，它是一款 CI/CD 工具。不管你是在尋找一款新的 CI/CD 工具，還是在考慮整合你的整個工具鏈，Atlassian 服務端產品終止服務支持這件事都是一個很好的機會來讓你的團隊遷移到極狐GitLab，從而體驗端到端的一體化 DevSecOps 平台所帶來的眾多功能優勢，諸如自動化、可擴展性以及安全性。

在本文中，我們將會講述一些可以用來從 Bamboo CI/CD 遷移到極狐GitLab CI/CD 的步驟。

極狐GitLab CI/CD 和 Bamboo 有什麼不同

組織

Bamboo 是圍繞項目和計劃構造的。CI/CD 作業分為多個 stage，它們和其他決定作業如何運行的配置一起定義在 Bamboo 計劃中。Bamboo 項目用來對計劃進行組織管理，而且又可以細分為構建計劃和部署計劃。

顧名思義，構建計劃就是從配置倉庫拉取源代碼並且生成製品。這些製品能夠被定義在部署計劃中的作業使用，然後將其部署到定義在 Bamboo 中的目標環境上。Bamboo 作業又是由 task 組成，task 可能是一個腳本，比如從源代碼倉庫拉取源代碼。

你還需要將倉庫添加到 Bamboo 計劃或項目中，以便讓其下面的所有計劃都能夠看到此倉庫，而且還要設置一些觸發器，比如 Bamboo 如何檢測變更以及如何運行構建等。

極狐GitLab 的組織是完全不同的。一切都在一個單一應用程序裏面，CI/CD 的配置以 .gitlab-ci.yml 文件的形式存在，而此文件又是整個源代碼的一部分。當然，如果你開啓了 Auto DevOps 功能，那麼在你的項目中你是看不到 .gitlab-ci.yml 文件的，但是 CI/CD 流水線是會自動執行的。

極狐GitLab CI/CD 的配置也是由 job 組成，也是分 stage 的。作業的觸發規則是由 CI/CD 的 rules 來控制的，而且對於部署來説並沒有單獨的配置。部署作業可以定義在同一個 CI/CD 腳本中，用 deploy stage 聲明即可，這個過程可以使用部署環境相關的設置。

Agent vs Runner

Bamboo 使用 Agent 來運行構建和部署。Agent 可能運行在 Bamboo 服務器上，也可能運行在服務器外部。極狐GitLab 使用了一個和 Agent 非常相似的概念，也就是極狐GitLab Runner，通過使用執行器來運行構建。典型的執行器包括 SSH、Docker 以及 Kubernetes。你可以選擇使用極狐GitLab SaaS 自帶的 Runner，也可以選擇自己部署安裝 Runner。

Bamboo 聲明（Specs）vs .gitlab-ci.yml 文件

Bamboo 主要是通過 Bamboo UI 來進行配置，當然也可以使用 Bamboo 聲明（Specs）將流程配置為代碼。Bamboo 聲明可以使用 Java 和其他 JVM 語言，或者使用 YAML 語法來進行定義。但是 JAVA 比 YAML 具有更完整的功能覆蓋。Bamboo 聲明可以被定義且存儲在聲明倉庫裏，然後將其鏈接到 Bamboo 項目中。

而 .gitlab-ci.yml 文件是極狐GitLab CI/CD 工作流的核心。當項目中包含此文件時，文件中定義的流程就會被執行（當 CI/CD 被觸發時），此外，如果開啓了 Auto DevOps ，那麼就會自動構建和部署應用程序。在某些複雜的用例場景下，還可以使用模板（templates）和 CI/CD 組件（components）來進一步簡化流水線的構建。

極狐GitLab 是如何加速工作流的？

除了構建和部署應用程序外，極狐GitLab 還提供了一系列其他功能來讓應用程序的構建變得更加安全、快速以及高效。這些功能包括：

應用程序安全：極狐GitLab 使用諸多安全掃描手段對軟件研發生命週期的各個階段進行安全掃描，這些手段包括：靜態應用程序安全測試（SAST）、密鑰檢測、基礎設施即代碼（IaC）掃描、依賴項掃描、許可證掃描、基於覆蓋率的模糊測試（Fuzz Testing）、容器鏡像掃描、API 安全、動態應用程序安全測試（DAST）以及運維安全掃描。
合規和安全策略： 能夠真正理解安全掃描結果並且讓策略真正起作用，對於確保應用程序安全來説至關重要。你可以通過設置掃描執行或結果策略來確保添加的額外掃描或審核要求，能夠符合法規或者企業自身制定的一些安全要求。
CI/CD 目錄：可以在多個項目中使用的 CI/CD 配置片段可以轉化成組件（component），然後存儲到組件倉庫中，以便讓其他人在 CI/CD 目錄中來使用這些配置片段。
軟件包和倉庫： 可以將常用的一些軟件包託管在極狐GitLab 軟件包倉庫中。你還可以使用極狐GitLab 鏡像倉庫來託管容器鏡像，用極狐GitLab Terraform 模塊倉庫來託管 Terraform 模塊。如果你經常使用一些公開的鏡像或者軟件包，你還可以使用極狐GitLab 依賴項代理來維護一個本地的存儲。

將 Bamboo 聲明轉換為 .gitlab-ci.yml 腳本

回到這篇文章的初心，我們先來重點關注 Bamboo YAML 聲明。你可以將你的 Bamboo 計劃導成 YAML 聲明，具體思路可以參考 Atlassian 的這篇官方文檔。接下來，就來看看如何將 Bamboo YAML 聲明轉換為極狐GitLab CI/CD 配置。

容器鏡像（Container image）

首先需要定義的是作業運行時所需要的容器鏡像。默認情況下，Bamboo 使用 Agent，而且與 Agent 所在的機器配置息息相關。

如果你的 Babmoo 作業已經在容器鏡像裏面運行了，那麼 Bamboo 聲明可能會是下面這樣的：

---
version: 2
# ...
docker: ubuntu

這種定義通常是在作業級別進行配置。而到了極狐GitLab 中，定義就變成了：

image: ubuntu

如果想要學習如何在容器內運行極狐GitLab CI/CD 作業，可以查看這篇官方文檔。如果你沒有使用容器來運行 CI/CD 流水線，你也可以使用其他執行器來運行作業。

階段（Stages）

在 Bamboo 中，首先定義的就是 stages 以及與其關聯的一系列作業，這些都會放在作業的定義之前：

version: 2
stages:
  - First Stage:
      jobs:
        - Job 1A 
        - Job 1B
  - Second Stage:
      jobs:
        - Job 2A 
        - Job 2B

Job 1A:
  tasks:
    - clean
    - script
        - touch file1A.txt

Job 1B:
  tasks:
    - clean
    - script
        - touch file1B.txt

Job 2A:
  tasks:
    - clean
    - script
        - touch file2A.txt

Job 2B:
  tasks:
    - clean
    - script
        - touch file2B.txt

而在極狐GitLab 中，stages 是按照一定順序羅列的，然後定義了每一個作業在哪個 stage 下面運行：

stages:
  - build
  - test
  - deploy

job1:
  stage: build
  script:
    - echo "This job compiles code."

job2:
  stage: test
  script:
    - echo "This job tests the compiled code. It runs when the build stage completes."

job3:
  script:
    - echo "This job also runs in the test stage".

job4:
  stage: deploy
  script:
    - echo "This job deploys the code. It runs when the test stage completes."
  environment: production

同一個 stage 下面的作業都是並行執行的，只有執行成功之後才會去執行下一個 stage。當然，如果在一些複雜的流水線中，也可以使用關鍵字 needs 來改變這種執行順序。

變量

Bamboo 有好幾種變量：系統變量、全局變量、項目變量、計劃變量以及構建指定變量，可以使用 ${system.variableName} 語法來讀取系統變量，其他的變量則可以用語法 ${bamboo.variableName} 來讀取。當在腳本中訪問變量時，只需要將上面語法中的句號（.）換成下劃線（_）即可。

version: 2
# ...
variables:
  username: admin
  releaseType: milestone

Default job:
  tasks:
    - script: echo 'Release Type is $bamboo_releaseType'

在極狐GitLab 中，變量可以定義在好幾個層次，比如針對羣組的、項目的、CI 腳本以及作業的。如果是私有化部署的極狐GitLab 實例，管理員還可以定義實例級別的變量。極狐GitLab 的變量又可以分為受保護的（protected）、隱藏的（masking）以及擴展的（expanding）。受保護的變量只能被運行在默認或者受保護分支上的流水線所訪問。

以下是一個示例：

variables:
  GLOBAL_VAR: "A global variable"

job1:
  variables:
    JOB_VAR: "A job variable"
  script:
    - echo "Variables are '$GLOBAL_VAR' and '$JOB_VAR'"

job2:
  script:
    - echo "Variables are '$GLOBAL_VAR' and '$JOB_VAR'"

構建作業

Bamboo 的構建作業是由 task 組成，每一個都是可執行的最小單元，比如拉取源代碼或者將變量注入到腳本中。

version: 2
stages:
  - Run Tests:
      jobs:
        - Test Ruby 

Test Ruby :
  key: TEST
  tasks:
  - checkout:
      force-clean-build: false
      description: Checkout Default Repository
  - script:
      interpreter: SHELL
      scripts:
      - |-
        ruby -v  # Print out ruby version for debugging
        bundle config set --local deployment true  
        bundle install -j $(nproc)
        rubocop
        rspec spec
      description: run bundler & rspec

上面的例子中，計劃（plan）有兩個 task：拉取源代碼和一個執行腳本。拉取代碼 task 拉取了倉庫中的最新代碼，這樣後面的腳本 task 就能夠用拉取的代碼執行一些命令了。

極狐GitLab 的作業也是由一些腳本命令組成的：

image: ruby:latest

stages:
  - test

rspec:
  stage: test
  script:
    - ruby -v
    - bundle config set --local deployment true 
    - bundle install -j $(nproc)
    - rubocop
    - rspec spec

上面的例子中，定義了一個作業，在 test stage 下運行。而 script 中定義的內容需要極狐GitLab Runner 來執行。

在 Bamboo 中，你也可以在 task 中使用 Ant、Maven 或者 PHPUnit 來構建你的應用程序。在極狐GitLab 中，可以將你想要的二進制文件構建成一個鏡像，然後在 CI/CD 鏡像中使用它。

部署作業

在 Bamboo 中。部署項目用來進行軟件版本發佈或者環境部署。一個具有版本發佈定義的部署計劃示例如下：

---
version: 2

deployment:
  name: Release Software
  source-plan: BUILD-APP

release-naming: release-1.1

對於版本發佈來説，你指定了它能夠從哪個計劃中獲得生成的製品。而對於部署到具體的環境來講，示例如下：

---
version: 2
# ...
environments:
  - Test
  - QA
  - Prod

Test:
  tasks:
    - clean
    - artifact-download:
        destination: /workdir

在極狐GitLab CI/CD 中，你可以創建一個部署作業用來將製品部署到具體的環境或者創建一個版本。如果要部署到某一個環境，你可以使用 environment 關鍵字：

deploy-to-production:
  stage: deploy
  script:
    - # Run Deployment script
    - ./.ci/deploy_prod.sh
  environment:
    name: production

如果你正在創建一個版本，那麼你可以同時使用 release 關鍵字和 release-cli 工具來為 Git tags 創建版本。release 部分會在 script 之後執行，因此 script 部分必須存在。如果你沒有任何需要執行的腳本命令，那麼你可以使用佔位符，比如打印一條消息：

release_job:
  stage: release
  image: registry.gitlab.com/gitlab-org/release-cli:latest
  rules:
    - if: $CI_COMMIT_TAG                  # Run this job when a tag is created manually
  script:
    - echo "Building release version"
  release:
    tag_name: $CI_COMMIT_TAG
    name: 'Release $CI_COMMIT_TAG'
    description: 'Release created using the release-cli.'

Rules 和 workflow

在 Bamboo 中，可以使用 trigger 來控制作業的執行。trigger 可以是對代碼倉庫變更的定期輪詢，也可以是通過 webhook 來接受倉庫變更的事件通知。可以在 Bamboo 的 UI 界面上來配置 trigger 所需的條件，這樣可以確保只有在其他計劃執行通過後才能運行此構建。

trigger 示例：

---
version: 2
triggers:
  - polling: 130
  - cron: 0 * * * ? *

在極狐GitLab 中，可以通過代碼的提交/推送、合併、手動、定時或者流水線訂閲的方式來觸發 CI/CD 流水線。流水線中的作業還可以使用關鍵字 rules 或 workflow 來做進一步的控制。更多內容，可以學習極狐GitLab CI/CD 中的作業控制及流水線 workflow。

下面是一個在極狐GitLab CI/CD 中使用 rules 的例子：

workflow:
  rules:
    - changes:
      - .gitlab/**/**.md
      when: never

上面的例子顯示，當 .gitlab 文件夾下面的 .md 文件發生變更時，不會觸發流水線。

製品

不管是是極狐GitLab 還是在 Bamboo 中，都可以使用關鍵詞 artifacts 來定義製品。

在 Bamboo 中，artifacts 的定義如下：

---
version: 2
# ...
  artifacts:
    -
      name: Test Reports
      location: target/reports
      pattern: '*.xml'
      required: false
      shared: false
    -
      name: Special Reports
      location: target/reports
      pattern: 'special/*.xml'
      shared: true

在上面的 Bamboo 聲明中，artifacts 定義了一個名稱、位置、模式以及可選的共享能力，用來將 artifacts 共享給其他的作業或者計劃。你還可以進一步地定義作業以便它們能夠訂閲這些 artifacts。

可以使用 artifact-subscriptions 來在同一個計劃中的其他作業中來訪問 artifacts：

Test app:
  artifact-subscriptions:
    -
      artifact: Test Reports
      destination: deploy

可以使用 artifact-download 來在不同的計劃的作業中訪問 artifacts：

---
version: 2
# ...
  tasks:
    - artifact-download: 
        source-plan: PROJECTKEY-PLANKEY

在 source-plan 關鍵字中，你需要提供一些關鍵信息，比如你想從哪個計劃來下載製品。

在極狐GitLab 中，之前 stage 中已完成作業中的製品都是默認可下載的。下面是一個在極狐GitLab 中定義製品的示例：

pdf:
  script: xelatex mycv.tex
  artifacts:
    name: "pdf-files"
    public: false
    untracked: true
    paths:
      - pdfs/
    exclude:
      - pdfs/*.tex

在上面的 CI/CD 腳本中：

需要指定製品的名稱。你也可以選擇通過使用 CI/CD 變量來動態指定。
public 關鍵字用來設置製品的訪問屬性，比如是否可以公開可用。在極狐GitLab 私有化部署實例中，這個默認是不開啓的。管理員可以使用功能開關 non_public_artifacts 來開啓此項功能。
你還可以使用 untracked 和 paths 關鍵字來包含或者排除 Git 中的非追蹤文件。

更多詳情可以查看極狐GitLab CI/CD 作業製品的用法。

如何設置遷移計劃

從 Bamboo 遷移到極狐GitLab CI/CD 並不是從將 Bamboo 計劃轉換為極狐GitLab CI/CD 腳本開始。而是開始與你與領導層及利益相干者的清晰溝通，並且基於此溝通達成了共同的遷移願景。 一旦獲得了必要的支持，就可以按照以下步驟開始遷移了：

將項目導入到極狐GitLab；
確定構建應用程序所必需的二進制文件及構建工具，以及它們所需的各種依賴；
定義流水線的工作流，比如，作業之間的項目依賴，必要的觸發等；
學習極狐GitLab CI/CD 功能的使用；
識別流水線中所需的密鑰憑據和變量，然後將它們定義在項目 CI/CD 的設置中，或者使用其他的密鑰管理器來進行管理；
根據實踐指南來創建第一個極狐GitLab 流水線，然後學習更復雜的流水線；
持續迭代並且測試極狐GitLab CI/CD 流水線，還要經常審查學習 .gitlab-ci.yml 中關鍵字的用法。

極狐GitLab 博客

極狐GitLab 博客

博客 / 詳情