从 Bamboo 到极狐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 中关键字的用法。