Help us learn about your current experience with the documentation. Take the survey.

从Bamboo迁移

层级：Free、Premium、Ultimate
提供方式：GitLab.com、GitLab Self-Managed、GitLab Dedicated

本迁移指南介绍如何从Atlassian Bamboo迁移到GitLab CI/CD。
重点针对从Bamboo界面导出或存储在Spec仓库中的Bamboo Specs YAML。

GitLab CI/CD入门

如果您刚接触GitLab CI/CD，可以使用入门指南了解基本概念及如何创建首个.gitlab-ci.yml文件。
若您已有GitLab CI/CD使用经验，可查阅CI/CD YAML语法参考，查看完整的可用关键词列表。

您还可以了解Auto DevOps，它通过预配置功能和集成集合，自动构建、测试并部署您的应用程序。

关键相似点与差异

提供方式

Atlassian以Cloud（SaaS）或Data center（自托管）形式提供Bamboo。
第三种Server选项计划于2024年2月15日终止支持（EOL）。

这些选项类似于GitLab.com和GitLab Self-Managed。GitLab还提供GitLab Dedicated，一种完全隔离的单租户SaaS服务。

代理与运行器

Bamboo使用agents运行构建和部署。Agent可以是运行在Bamboo服务器上的本地Agent，或是运行在外部服务器上的远程Agent。

GitLab采用类似代理的概念，称为runners，其利用executors执行构建。

示例executor包括shell、Docker或Kubernetes。您可选择使用GitLab.com runners，或自行部署self-managed runners。

工作流

Bamboo工作流被组织为项目。项目用于组织Plans，以及多个Plan所需的变量、共享凭证和权限。一个Plan将作业分组到阶段，并链接至托管待构建应用的代码仓库（可能是Bitbucket、GitLab或其他服务）。

GitLab CI/CD采用类似工作流。作业被组织到阶段中，项目拥有独立的.gitlab-ci.yml配置文件或包含现有模板。

模板与配置即代码

Bamboo Specs

Bamboo Plan可通过Web UI或Bamboo Specs进行配置。Bamboo Specs是配置即代码，可编写为Java或YAML。YAML Specs最易使用，但Bamboo功能覆盖不足；Java Specs功能完备，可使用Groovy、Scala或Kotlin等JVM语言编写。
若您通过Web UI配置Plan，可将Bamboo配置导出到Bamboo Specs。

Bamboo Specs也可存储在仓库中。

`.gitlab-ci.yml` 配置文件

默认情况下，GitLab 使用 .gitlab-ci.yml 文件进行 CI/CD 配置。
此外，Auto DevOps 可以自动构建、测试和部署您的应用程序，无需手动配置 .gitlab-ci.yml 文件。

GitLab CI/CD 配置可以组织为可在项目间重复使用的模板。
GitLab 还提供了预建的模板，帮助您快速入门并避免重复造轮子。

配置

Bamboo YAML 规范语法

此 Bamboo 规范是从 Bamboo Server 实例导出的，生成的输出相当冗长：

version: 2
plan:
  project-key: AB
  key: TP
  name: 测试计划
stages:
  - Default Stage:
      manual: false
      final: false
      jobs:
        - Default Job
Default Job:
  key: JOB1
  tasks:
  - checkout:
      force-clean-build: false
      description: 检出默认仓库
  - script:
      interpreter: SHELL
      scripts:
        - |- 
          ruby -v  # 打印 Ruby 版本用于调试
          bundle config set --local deployment true  # 将依赖安装到 ./vendor/ruby
          bundle install -j $(nproc)
          rubocop
          rspec spec
      description: 运行 Bundler
  artifact-subscriptions: []
repositories:
  - Demo Project:
      scope: global
triggers:
  - polling:
      period: '180'
branches:
  create: manually
  delete: never
  link-to-jira: true
notifications: []
labels: []
dependencies:
  require-all-stages-passing: false
  enabled-for-branches: true
  block-strategy: none
  plans: []
other:
  concurrent-build-plugin: system-default

---

version: 2
plan:
  key: AB-TP
plan-permissions:
  - users:
    - root
    permissions:
    - view
    - edit
    - build
    - clone
    - admin
    - view-configuration
  - roles:
    - logged-in
    - anonymous
    permissions:
    - view
...

具有类似行为的 GitLab CI/CD .gitlab-ci.yml 配置如下：

default:
  image: ruby:latest

stages:
  - default-stage

job1:
  stage: default-stage
  script:
    - ruby -v  # 打印 Ruby 版本用于调试
    - bundle config set --local deployment true  # 将依赖安装到 ./vendor/ruby
    - bundle install -j $(nproc)
    - rubocop
    - rspec spec

常见配置

本节回顾一些常见的 Bamboo 配置及其对应的 GitLab CI/CD 配置。

工作流

Bamboo 的结构与 GitLab CI/CD 不同。在 GitLab 中，可以通过多种方式启用项目的 CI/CD：向项目中添加 .gitlab-ci.yml 文件、项目所属组中存在合规管道，或启用 AutoDevOps。使用 AutoDevOps 时，管道会根据规则或上下文自动触发。

Bamboo 的结构不同，需要将仓库添加到 Bamboo 项目，并提供身份验证，并设置触发器。添加到项目中的仓库对所有计划都可用。用于测试和构建应用程序的计划称为构建计划（Build plans）。

构建计划

Bamboo 中的构建计划由按顺序运行的阶段组成，以构建应用程序并在相关时生成工件。构建计划需要一个附加的默认仓库，或继承父项目的链接仓库。可以在计划级别定义变量、触发器和不同计划之间的关系。

以下是一个 Bamboo 构建计划的示例：

version: 2
plan:
  project-key: SAMPLE
  name: 构建 Ruby 应用
  key: BUILD-APP

stages:
  - 测试应用:
      jobs:
        - 测试应用程序
        - 执行安全检查
  - 构建应用:
      jobs:
        - 构建应用程序

测试应用程序:
  tasks:
    - script:
        - # 运行测试

执行安全检查:
  tasks:
    - script:
        - # 运行安全检查

构建应用程序:
  tasks:
    - script:
        - # 运行构建

在此示例中：

计划规范包含一个 YAML 规范版本。版本 2 是最新的。
project-key 将计划链接到其父项目。创建项目时指定该键。
计划 key 唯一标识该计划。

在 GitLab CI/CD 中，Bamboo 构建计划类似于项目中的 .gitlab-ci.yml 文件，它可以包含来自其他项目或模板的 CI/CD 脚本。

等效的 GitLab CI/CD .gitlab-ci.yml 文件如下：

default:
  image: alpine:latest

stages:
  - test
  - build

测试应用程序:
  stage: test
  script:
    - # 运行测试

安全检查:
  stage: test
  script:
    - # 运行安全检查

构建应用程序:
  stage: build
  script:
    - # 运行构建

容器镜像

构建和部署默认由Bamboo代理的原生操作系统运行，但可配置为在容器中运行。要让作业在容器中运行， Bamboo会在计划或作业级别使用docker关键字。

例如，在Bamboo构建计划中：

version: 2
plan:
  project-key: SAMPLE
  name: 构建Ruby应用
  key: BUILD-APP

docker: alpine:latest

stages:
  - 构建应用:
      jobs:
        - 构建应用程序

构建应用程序:
  tasks:
    - script:
        - # 运行构建
  docker:
    image: alpine:edge

在GitLab CI/CD中，您只需使用image关键字。

等效的GitLab CI/CD .gitlab-ci.yml 文件如下：

default:
  image: alpine:latest

stages:
  - 构建

构建应用程序:
  stage: 构建
  script:
    - # 运行构建
  image:
    name: alpine:edge

变量

Bamboo有以下基于范围类型的变量：

构建特定变量：在构建时评估。例如 ${bamboo.planKey}。
系统变量：从Bamboo实例或系统环境继承而来。
全局变量：为整个实例定义，可供每个计划访问。
项目变量：特定于项目，同一项目内的计划均可访问。
计划变量：特定于某个计划。

您可以使用格式 ${system.variableName} 访问Bamboo的系统变量，其他类型变量则使用 ${bamboo.variableName}。当在脚本任务中使用变量时，点号会转换为下划线，${bamboo.variableName} 变为 $bamboo_variableName。

在GitLab中，您可以在以下级别定义CI/CD变量：

实例
组
项目
在 .gitlab-ci.yml 文件中作为所有作业的默认变量
在 .gitlab-ci.yml 文件中作为单个作业的变量

与Bamboo的系统变量和全局变量类似，GitLab也有预定义CI/CD变量，可供每个作业使用。

在CI/CD脚本中定义变量的方式在Bamboo和GitLab中相似。

例如，在Bamboo构建计划中：

version: 2

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

默认作业:
  tasks:
    - script: echo '$bamboo_username 是 $bamboo_releaseType 的DRI'

等效的GitLab CI/CD .gitlab-ci.yml 文件如下：

variables:
  DEFAULT_VAR: "一个默认变量"

job1:
  variables:
    JOB_VAR: "一个作业变量"
  script:
    - echo "变量是 '$DEFAULT_VAR' 和 '$JOB_VAR'"

在GitLab CI/CD中，变量像常规Shell脚本变量一样访问。例如，$VARIABLE_NAME。

作业与任务

在GitLab和Bamboo中，同一阶段的作业会并行运行，除非存在需要在作业运行前满足的依赖关系。

Bamboo中可运行的作业数量取决于Bamboo代理的可用性和Bamboo许可证规模。GitLab CI/CD 中并行作业的数量取决于集成到GitLab实例的runner数量以及runner中设置的并发值。

在Bamboo中，作业由任务组成，这些任务可以是：

一组作为脚本运行的命令
预定义任务，如源码检出、工件下载，以及其他可在Atlassian 任务市场中获取的任务。

例如，在Bamboo构建计划中：

version: 2
#...

默认作业:
  key: JOB1
  tasks:
  - checkout:
      force-clean-build: false
      description: 检出默认仓库
  - script:
      interpreter: SHELL
      scripts:
        - |-
          ruby -v
          bundle config set --local deployment true
          bundle install -j $(nproc)
      description: 运行bundler
other:
  concurrent-build-plugin: system-default

GitLab中任务的等效项是script，它指定runner执行的命令。

例如，在GitLab CI/CD .gitlab-ci.yml 文件中：

job1:
  script: "bundle exec rspec"

job2:
  script:
    - ruby -v
    - bundle config set --local deployment true
    - bundle install -j $(nproc)

借助GitLab，您可以使用CI/CD模板和CI/CD组件来组合您的流水线，无需自行编写所有内容。

条件判断

在Bamboo中，每个任务都可以有决定任务是否运行的条件。

例如，在Bamboo构建计划中：

version: 2

任务：

脚本：解释器：SHELL 脚本： - echo “Hello” 条件： - 变量：等于： planRepository.branch: development

在GitLab中，这可以通过rules关键字实现，用于控制作业何时运行。

例如，在GitLab CI/CD的.gitlab-ci.yml文件中：

job:
  script: echo "Hello, Rules!"
  rules:
    - if: $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME = development

触发器

Bamboo有多种触发构建的选项（触发构建），这些选项可以基于代码变更、计划、其他计划的执行结果或按需触发。

一个计划可以被配置为定期轮询项目以获取新变更。

例如，在Bamboo构建计划中：

version: 2
#...
triggers:
  - polling:
      period: '180'

GitLab CI/CD管道可以根据代码变更、计划或由其他作业或API调用触发。GitLab CI/CD管道不需要使用轮询，也可以按计划触发。

你可以使用workflow关键字和rules来配置管道本身的运行时机。

例如，在GitLab CI/CD的.gitlab-ci.yml文件中：

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

工件

你可以在GitLab和Bamboo中使用artifacts关键字定义作业工件。

例如，在Bamboo构建计划中：

version: 2

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

在此示例中，工件通过名称、位置和模式定义。你也可以与其他作业和计划共享工件，或定义订阅该工件的作业。

artifact-subscriptions用于访问同一计划中另一个作业的工件，例如：

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

artifact-download用于访问不同计划中作业的工件，例如：

version: 2

# ...
Build:
  # ...
  tasks:
    - artifact-download:
        source-plan: PROJECTKEY-PLANKEY

你需要在使用source-plan关键字时提供你要下载工件的计划键。

在GitLab中，默认会下载之前阶段已完成作业的所有工件。

例如，在GitLab CI/CD的.gitlab-ci.yml文件中：

stages:
  - build

pdf:
  stage: build
  script: #generate XML reports
  artifacts:
    name: "test-report-files"
    untracked: true
    paths:
      - target/reports

在此示例中：

工件的名称被显式指定，但你也可以使用CI/CD变量使其动态化。
untracked关键字设置工件同时包含Git未跟踪文件以及通过paths明确指定的文件。

缓存

在Bamboo中，Git缓存可用于加速构建。Git缓存是在Bamboo管理设置中配置的，存储在Bamboo服务器或远程代理上。

GitLab支持Git缓存和作业缓存。缓存是通过每个作业使用cache关键字定义的。

例如，在GitLab CI/CD的.gitlab-ci.yml文件中：

test-job:
  stage: build
  cache:
    - key:
        files:
          - Gemfile.lock
      paths:
        - vendor/ruby
    - key:
        files:
          - yarn.lock
      paths:
        - .yarn-cache/
  script:
    - bundle config set --local path 'vendor/ruby'
    - bundle install
    - yarn install --cache-folder .yarn-cache
    - echo Run tests...

部署项目

Bamboo 有部署项目，它会关联构建计划以跟踪、获取并将工件部署到部署环境。

创建项目时，您需将其关联到构建计划，指定部署环境及执行部署的任务。A 部署任务可以是脚本或来自 Atlassian 市场中的 Bamboo 任务。

例如在部署项目规范中：

version: 2

deployment:
  name: 部署 Ruby 应用
  source-plan: build-app

release-naming: release-1.0

environments:
  - Production

Production:
  tasks:
    - # 用于将应用部署到生产环境的脚本
    - ./.ci/deploy_prod.sh

在 GitLab CI/CD 中，您可以创建一个部署作业，该作业可部署到环境或创建发布。

例如在 GitLab CI/CD 的 .gitlab-ci.yml 文件中：

deploy-to-production:
  stage: deploy
  script:
    - # 运行部署脚本
    - ./.ci/deploy_prod.sh
  environment:
    name: production

若要创建发布，可使用 release 关键字结合 release-cli 工具为 Git 标签创建发布。

例如在 GitLab CI/CD 的 .gitlab-ci.yml 文件中：

release_job:
  stage: release
  image: registry.gitlab.com/gitlab-org/release-cli:latest
  rules:
    - if: $CI_COMMIT_TAG                  # 当手动创建标签时运行此作业
  script:
    - echo "构建发布版本"
  release:
    tag_name: $CI_COMMIT_TAG
    name: '发布 $CI_COMMIT_TAG'
    description: '使用 release-cli 创建的发布。'

安全扫描功能

Bamboo 依赖 Atlassian 市场中提供的第三方任务来运行安全扫描。GitLab 提供开箱即用的安全扫描器，用于检测 SDLC 各环节的漏洞。您可通过模板向 GitLab 添加这些插件，例如为管道添加 SAST 扫描，可在 .gitlab-ci.yml 中加入：

include:
  - template: Jobs/SAST.gitlab-ci.yml

您可通过 CI/CD 变量自定义安全扫描器的行为，例如使用 SAST 扫描器时。

密钥管理

特权信息（通常称为“密钥”）是您在 CI/CD 工作流中需要的敏感信息或凭据。您可能用密钥解锁受保护资源或在工具、应用、容器及云原生环境中访问敏感信息。

Bamboo 中的密钥管理通常通过共享凭证或 Atlassian 市场中的第三方应用处理。

对于 GitLab 中的密钥管理，您可使用外部服务的支持集成之一。这些服务会在 GitLab 项目外安全存储密钥，但您需订阅对应服务：

GitLab 还支持 OIDC 认证用于其他支持 OIDC 的第三方服务。

此外，您可将凭据存储在 CI/CD 变量中以供作业使用，但明文存储的密钥易意外泄露，与 Bamboo 相同。您应始终将敏感信息存储在掩码和受保护变量中，以此降低风险。

另外，切勿将密钥作为变量存储在您的 .gitlab-ci.yml 文件中——该文件对所有有权访问项目的用户公开。仅应在项目、组或实例设置中存储敏感信息的变量。

查看安全指南以提升 CI/CD 变量的安全性。

迁移计划

以下是观察能快速完成此迁移的组织后总结的建议步骤列表。

创建迁移计划

在开始迁移之前，你应该创建一个迁移计划，为迁移做准备。对于从Bamboo进行的迁移，请准备时问自己以下问题：

当前Bamboo作业中使用了哪些Bamboo任务？
- 你确切知道这些任务的作用吗？
- 是否有任何任务封装了常用的构建工具？例如Maven、Gradle或NPM？
Bamboo代理上安装了什么？
是否在使用共享库？
你是如何从Bamboo进行身份验证的？你是使用SSH密钥、API令牌还是其他机密信息？
你的管道是否需要访问其他项目？
Bamboo中是否有用于访问外部服务的凭证？例如Ansible Tower、Artifactory或其他云提供商或部署目标？

先决条件

在进行任何迁移工作之前，你应该首先：

熟悉GitLab。
- 阅读有关key GitLab CI/CD功能的内容。
- 按照教程创建your first GitLab pipeline以及构建、测试和部署静态站点的更复杂的管道。
- 查看CI/CD YAML语法参考。
设置并配置GitLab。
测试你的GitLab实例。
- 确保runner可用，可以通过使用共享的GitLab.com runner或安装新的runner来实现。

迁移步骤

将项目从你的SCM解决方案迁移到GitLab。
- (推荐) 你可以使用可用的导入器来自动化从外部SCM提供商的大规模导入。
- 你可以通过URL导入仓库。
在每个项目中创建一个.gitlab-ci.yml文件。
将你的Bamboo项目和计划导出为YAML规范。
将Bamboo YAML规范配置迁移到GitLab CI/CD作业中，并配置它们以直接在合并请求中显示结果。
通过使用云部署模板、环境和GitLab Kubernetes代理来迁移部署作业。
检查是否可以在不同项目之间重用任何CI/CD配置，然后创建并共享CI/CD模板。
查看pipeline效率文档，了解如何使你的GitLab CI/CD管道更快、更高效。

如果你有这里未解答的问题，GitLab社区论坛是一个很好的资源。

从Bamboo迁移

GitLab CI/CD入门

关键相似点与差异

提供方式

代理与运行器

工作流

模板与配置即代码

Bamboo Specs

.gitlab-ci.yml 配置文件

配置

Bamboo YAML 规范语法

常见配置

工作流

构建计划

容器镜像

变量

作业与任务

条件判断

触发器

工件

缓存

部署项目

安全扫描功能

密钥管理

迁移计划

创建迁移计划

先决条件

迁移步骤

`.gitlab-ci.yml` 配置文件