从 Bamboo 迁移到极狐GitLab CI/CD

极狐GitLab CI/CD 入门
关键相似点和不同点

Tier: 基础版，专业版，旗舰版
Offering: JihuLab.com, 私有化部署

本迁移指南介绍了如何从 Atlassian Bamboo 迁移到极狐GitLab CI/CD。重点是从 Bamboo UI 导出或存储在 Spec 仓库中的 Bamboo Specs YAML。

极狐GitLab CI/CD 入门

如果您是极狐GitLab CI/CD 的新手，请使用入门指南了解基本概念以及如何创建您的第一个 .gitlab-ci.yml 文件。如果您已经有一些使用极狐GitLab CI/CD 的经验，可以查看 CI/CD YAML 语法参考以查看可用关键字的完整列表。

您还可以查看 Auto DevOps，它使用一系列预配置的功能和集成自动构建、测试和部署您的应用程序。

关键相似点和不同点

提供

Atlassian 提供 Bamboo 的云（SaaS）或数据中心（自托管）选项。第三个服务器选项计划于 2024 年 2 月 15 日结束生命周期。这些选项类似于 JihuLab.com 和极狐GitLab 私有化部署。极狐GitLab 还提供极狐GitLab Dedicated，一种完全隔离的单租户 SaaS 服务。

代理与 Runner

Bamboo 使用代理来运行构建和部署。代理可以是运行在 Bamboo 服务器上的本地代理或在服务器之外运行的远程代理。

极狐GitLab 使用类似于代理的概念，称为 runner，它使用 executors 来运行构建。

executors 的示例包括 shell、Docker 或 Kubernetes。您可以选择使用 JihuLab.com runner 或部署您自己的私有化部署 runner。

工作流

Bamboo 工作流组织成项目。项目用于组织计划、变量、共享凭据以及多个计划所需的权限。计划将作业分组到阶段，并链接到托管要构建的应用程序的代码仓库。仓库可以在 Bitbucket、极狐GitLab 或其他服务中。

作业是在同一 Bamboo 代理上顺序执行的一系列任务。Bamboo 中的 CI 和部署是分开处理的。部署项目工作流与构建计划工作流不同。

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

模板化和代码化配置

Bamboo Specs

Bamboo 计划可以在 Web UI 或使用 Bamboo Specs 配置。Bamboo Specs是代码化配置，可以用 Java 或 YAML 编写。YAML Specs是最容易使用的，但在 Bamboo 功能覆盖方面存在不足。Java Specs 拥有完整的 Bamboo 功能覆盖，可以用任何 JVM 语言编写，如 Groovy、Scala 或 Kotlin。如果您使用 Web UI 配置计划，可以将您的 Bamboo 配置导出到 Bamboo Specs。

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

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

极狐GitLab CI/CD 配置可以组织成可跨项目重用的模板。极狐GitLab 还提供预构建的模板，帮助您快速入门，避免重复发明轮子。

配置

Bamboo YAML Spec 语法

此 Bamboo Spec 是从 Bamboo 服务器实例导出的，产生了相当冗长的输出：

version: 2
plan:
  project-key: AB
  key: TP
  name: test plan
stages:
  - Default Stage:
      manual: false
      final: false
      jobs:
        - Default Job
Default Job:
  key: JOB1
  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  # Install dependencies into ./vendor/ruby
          bundle install -j $(nproc)
          rubocop
          rspec spec
      description: run 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  # Print out ruby version for debugging
    - bundle config set --local deployment true  # Install dependencies into ./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 项目，提供身份验证并设置触发器。添加到项目中的仓库可用于项目中的所有计划。用于测试和构建应用程序的计划称为构建计划。

构建计划

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

Bamboo 构建计划的示例：

version: 2
plan:
  project-key: SAMPLE
  name: Build Ruby App
  key: BUILD-APP

stages:
  - Test App:
      jobs:
        - Test Application
        - Perform Security checks
  - Build App:
      jobs:
        - Build Application

Test Application:
  tasks:
    - script:
        - # Run tests

Perform Security checks:
  tasks:
    - script:
        - # Run Security Checks

Build Application:
  tasks:
    - script:
        - # Run buils

在此示例中：

计划 Specs 包括 YAML Spec 版本。版本 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

test-application:
  stage: test
  script:
    - # Run tests

security-checks:
  stage: test
  script:
    - # Run Security Checks

build-application:
  stage: build
  script:
    - # Run builds

容器镜像

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

例如，在 Bamboo 构建计划中：

version: 2
plan:
  project-key: SAMPLE
  name: Build Ruby App
  key: BUILD-APP

docker: alpine:latest

stages:
  - Build App:
      jobs:
        - Build Application

Build Application:
  tasks:
    - script:
        - # Run builds
  docker:
    image: alpine:edge

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

极狐GitLab CI/CD .gitlab-ci.yml 文件的等价文件为：

default:
  image: alpine:latest

stages:
  - build

build-application:
  stage: build
  script:
    - # Run builds
  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

Default job:
  tasks:
    - script: echo '$bamboo_username is the DRI for $bamboo_releaseType'

极狐GitLab CI/CD .gitlab-ci.yml 文件的等价文件为：

variables:
  DEFAULT_VAR: "A default variable"

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

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

作业和任务

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

在 Bamboo 中可以运行的作业数量取决于 Bamboo 代理的可用性和 Bamboo 许可证大小。对于极狐GitLab CI/CD，并行作业的数量取决于与极狐GitLab 实例集成的 runner 数量和 runner 中设置的并发性。

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

一组命令作为脚本运行
预定义任务，如源代码签出、产物下载和其他在 Atlassian 任务市场中可用的任务。

例如，在 Bamboo 构建计划中：

version: 2
#...

Default Job:
  key: JOB1
  tasks:
  - checkout:
      force-clean-build: false
      description: Checkout Default Repository
  - script:
      interpreter: SHELL
      scripts:
        - |-
          ruby -v
          bundle config set --local deployment true
          bundle install -j $(nproc)
      description: run 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 组件来构建您的流水线，而无需自己编写所有内容。

条件

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

例如，在 Bamboo 构建计划中：

version: 2
# ...
tasks:
  - script:
      interpreter: SHELL
      scripts:
        - echo "Hello"
      conditions:
        - variable:
            equals:
              planRepository.branch: development

在极狐GitLab 中，可以使用 rules 关键字来控制作业何时运行在极狐GitLab CI/CD 中。

例如，在极狐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 有部署项目，链接到构建计划以跟踪、获取和部署产物到部署环境。

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

例如在部署项目 Spec 中：

version: 2

deployment:
  name: Deploy ruby app
  source-plan: build-app

release-naming: release-1.0

environments:
  - Production

Production:
  tasks:
    - # scripts to deploy app to production
    - ./.ci/deploy_prod.sh

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

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

deploy-to-production:
  stage: deploy
  script:
    - # Run Deployment 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.cn/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.'

安全扫描功能

Bamboo 依赖 Atlassian Marketplace 中提供的第三方任务来运行安全扫描。极狐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。
- 阅读有关极狐GitLab CI/CD 的关键功能。
- 通过教程创建您的第一个极狐GitLab 流水线和更复杂的流水线，以构建、测试和部署静态站点。
- 查看 CI/CD YAML 语法参考。
设置和配置极狐GitLab。
测试您的极狐GitLab 实例。
- 确保 runner 可用，可以使用共享的 JihuLab.com runner 或安装新的 runner。

迁移步骤

将项目从您的 SCM 解决方案迁移到极狐GitLab。
- （推荐）您可以使用可用的导入器自动化从外部 SCM 提供商进行批量导入。
- 您可以通过 URL 导入仓库。
在每个项目中创建一个 .gitlab-ci.yml 文件。
将您的 Bamboo 项目/计划导出为 YAML Spec
将 Bamboo YAML Spec 配置迁移到极狐GitLab CI/CD 作业，并将其配置为直接在合并请求中显示结果。
通过使用云部署模板、环境和极狐GitLab 的 Kubernetes 代理迁移部署作业。
检查是否有任何 CI/CD 配置可以跨不同项目重用，然后创建并共享 CI/CD 模板。
查看流水线效率文档以了解如何使您的极狐GitLab CI/CD 流水线更快、更高效。

如果您有未在此处回答的问题，极狐GitLab 社区论坛可以成为一个很好的资源。

极狐GitLab CI/CD 入门

关键相似点和不同点

提供

代理与 Runner

工作流

模板化和代码化配置

Bamboo Specs

.gitlab-ci.yml 配置文件

配置

Bamboo YAML Spec 语法

常见配置

工作流

构建计划

容器镜像

变量

作业和任务

条件

触发器

产物

缓存

部署项目

安全扫描功能

密钥管理

迁移计划

创建迁移计划

先决条件

迁移步骤

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