从 TeamCity 迁移

如果您正从 TeamCity 迁移到 GitLab CI/CD，您可以创建能够复制并增强您 TeamCity 工作流程的 CI/CD 管道。

主要相似点和差异点

GitLab CI/CD 和 TeamCity 都是 CI/CD 工具，有一些相似之处。GitLab 和 TeamCity 都：

• 足够灵活，可以运行大多数语言的作业。
• 可以在本地或云端部署。

此外，两者之间还有一些重要差异：

• GitLab CI/CD 管道在 YAML 格式的配置文件中进行配置，您可以手动编辑或使用 管道编辑器 进行编辑。 TeamCity 管道可以从 UI 或使用 Kotlin DSL 进行配置。
• GitLab 是一个内置 SCM、容器注册表、安全扫描等功能的 DevSecOps 平台。 TeamCity 需要单独的解决方案来实现这些功能，通常通过集成提供。

配置文件

TeamCity 可以 从 UI 进行配置 或在 Kotlin DSL 格式的 Teamcity 配置文件 中配置。 TeamCity 构建配置是一组指令，定义了软件项目应该如何构建、测试和部署。 该配置包括在 TeamCity 中自动化 CI/CD 流程所需的参数和设置。

在 GitLab 中，TeamCity 构建配置的等效项是 .gitlab-ci.yml 文件。 该文件定义了项目的 CI/CD 管道，指定了构建、测试和部署项目所需的阶段、作业和命令。

功能和概念对比

许多 TeamCity 功能和概念在 GitLab 中都有等效功能，提供相同的功能。

作业

TeamCity 使用构建配置，包含多个构建步骤，您可以在其中定义执行任务（如编译代码、运行测试和打包工件）的命令或脚本。

以下是 Kotlin DSL 格式的 TeamCity 项目配置示例，用于构建 Docker 文件并运行单元测试：

package _Self.buildTypes

import jetbrains.buildServer.configs.kotlin.*
import jetbrains.buildServer.configs.kotlin.buildFeatures.perfmon
import jetbrains.buildServer.configs.kotlin.buildSteps.dockerCommand
import jetbrains.buildServer.configs.kotlin.buildSteps.nodeJS
import jetbrains.buildServer.configs.kotlin.triggers.vcs

object BuildTest : BuildType({
    name = "构建 & 测试"

    vcs {
        root(HttpsGitlabComRutshahCicdDemoGitRefsHeadsMain)
    }

    steps {
        dockerCommand {
            id = "DockerCommand"
            commandType = build {
                source = file {
                    path = "Dockerfile"
                }
            }
        }
        nodeJS {
            id = "nodejs_runner"
            workingDir = "app"
            shellScript = """
                npm install jest-teamcity --no-save
                npm run test -- --reporters=jest-teamcity
            """.trimIndent()
        }
    }

    triggers {
        vcs {
        }
    }

    features {
        perfmon {
        }
    }
})

在 GitLab CI/CD 中，您定义作业及其作为管道一部分要执行的任务。 每个作业可以包含一个或多个构建步骤。

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

workflow:
  rules:
    - if: $CI_COMMIT_BRANCH != "main" || $CI_PIPELINE_SOURCE != "merge_request_event"
      when: never
    - when: always

stages:
  - build
  - test

build-job:
  image: docker:20.10.16
  stage: build
  services:
    - docker:20.10.16-dind
  script:
    - docker build -t cicd-demo:0.1 .

run_unit_tests:
  image: node:17-alpine3.14
  stage: test
  before_script:
    - cd app
    - npm install
  script:
    - npm test
  artifacts:
    when: always
    reports:
      junit: app/junit.xml

管道触发器

TeamCity 触发器 定义启动构建的条件，包括 VCS 更改、 计划触发器或其他构建触发的构建。

在 GitLab CI/CD 中，管道可以在各种事件（如分支或合并请求更改以及新标签）时自动触发。 管道也可以通过 API 或 计划管道 手动触发。 更多信息请参见 CI/CD 管道。

变量

在 TeamCity 中，您在构建配置设置中 定义构建参数和环境变量。

在 GitLab 中，使用 variables 关键字定义 CI/CD 变量。 使用变量来重用配置数据，实现更动态的配置，或存储重要值。 变量可以全局定义或按作业定义。

例如，使用变量的 GitLab CI/CD .gitlab-ci.yml 文件：

default:
  image: alpine:latest

stages:
  - greet

variables:
  NAME: "Fern"

english:
  stage: greet
  variables:
    GREETING: "Hello"
  script:
    - echo "$GREETING $NAME"

spanish:
  stage: greet
  variables:
    GREETING: "Hola"
  script:
    - echo "$GREETING $NAME"

工件

TeamCity 中的构建配置允许您定义 构建过程中生成的工件。

在 GitLab 中，任何作业都可以使用 artifacts 关键字定义作业完成时要存储的一组工件。 工件 是可以在后续作业中使用的文件，用于测试或部署。

例如，使用工件的 GitLab CI/CD .gitlab-ci.yml 文件：

stage:
  - generate
  - use

generate_cat:
  stage: generate
  script:
    - touch cat.txt
    - echo "meow" > cat.txt
  artifacts:
    paths:
      - cat.txt
    expire_in: 1 week

use_cat:
  stage: use
  script:
    - cat cat.txt

Runner

GitLab 中 TeamCity 代理 的等效项是 Runner。

在 GitLab CI/CD 中，Runner 是执行作业的服务。如果您使用的是 GitLab.com，可以使用 实例 Runner 队列 来运行作业，而无需配置自己的自管理 Runner。

关于 Runner 的一些关键细节：

• Runner 可以 配置 为在实例间共享， 在组间共享，或专用于单个项目。
• 您可以使用 tags 关键字 进行更精细的控制，并将 Runner 与特定作业关联。例如，您可以为需要专用、更强大或特定硬件的作业使用标签。
• GitLab 有 Runner 自动扩展功能。 使用自动扩展仅在需要时配置 Runner，并在不需要时缩减规模。

TeamCity 构建功能 & 插件

TeamCity 中通过构建功能和插件启用的一些功能在 GitLab CI/CD 中通过 CI/CD 关键字和功能原生支持。

规划和执行迁移

以下推荐步骤列表是在观察能够快速完成迁移到 GitLab CI/CD 的组织后创建的。

创建迁移计划

在开始迁移之前，您应该创建一个 迁移计划 为迁移做准备。

对于从 TeamCity 的迁移，在准备时问自己以下问题：

• TeamCity 中的作业使用了哪些插件？
  • 您知道这些插件的具体功能吗？
• TeamCity 代理上安装了什么？
• 是否使用了共享库？
• 您如何从 TeamCity 进行身份验证？是否使用 SSH 密钥、API 令牌或其他机密信息？
• 是否有其他项目需要从您的管道访问？
• TeamCity 中是否有访问外部服务的凭据？例如 Ansible Tower、 Artifactory 或其他云服务提供商或部署目标？

先决条件

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

1. 熟悉 GitLab。
   • 阅读 关键 GitLab CI/CD 功能。
   • 按照教程创建 您的第一个 GitLab 管道 和 更复杂的管道， 这些管道构建、测试和部署静态网站。
   • 查看 CI/CD YAML 语法参考。
2. 设置和配置 GitLab。
3. 测试您的 GitLab 实例。
   • 确保 Runner 可用，要么使用共享的 GitLab.com Runner，要么安装新的 Runner。

迁移步骤

1. 将您的 SCM 解决方案中的项目迁移到 GitLab。
   • （推荐）您可以使用可用的 导入器 来自动化从外部 SCM 提供商批量导入。
   • 您可以 通过 URL 导入仓库。
2. 在每个项目中创建一个 .gitlab-ci.yml 文件。
3. 将 TeamCity 配置迁移到 GitLab CI/CD 作业，并配置它们直接在合并请求中显示结果。
4. 使用 云部署模板、 环境 和 GitLab Kubernetes 代理 迁移部署作业。
5. 检查是否有任何 CI/CD 配置可以跨不同项目重用，然后创建 并共享 CI/CD 模板 或 CI/CD 组件。
6. 查看 管道效率 了解如何使您的 GitLab CI/CD 管道更快、更高效。

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