• 关键相似点和不同点
  • 配置文件
• 功能和概念比较
  • 作业
  • 流水线触发器
  • 变量
  • 产物
  • Runners
  • TeamCity 构建功能和插件
• 规划和执行迁移
  • 创建迁移计划
  • 先决条件
  • 迁移步骤

{{< details >}}

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

{{< /details >}}

如果你正在从 TeamCity 迁移到极狐GitLab CI/CD，你可以创建流水线来复制和增强 TeamCity 的工作流程。

关键相似点和不同点

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

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

此外，两者之间还有一些重要的不同点：

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

配置文件

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

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

功能和概念比较

TeamCity 的许多功能和概念在极狐GitLab 中有等价物，提供相同的功能。

作业

TeamCity 使用构建配置，由多个构建步骤组成，你可以定义命令或脚本来执行任务，如编译代码、运行测试和软件包产物。

以下是一个 TeamCity 项目配置的 Kotlin DSL 格式示例，该项目构建一个 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 = "Build & Test"

    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

Runners

极狐GitLab 中的 TeamCity 代理等价物是 Runners。

在极狐GitLab CI/CD 中，runners 是执行作业的服务。如果你使用 JihuLab.com，你可以使用实例 runner fleet 来运行作业，无需自行配置私有化部署的 runners。

关于 runners 的一些关键细节：

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

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 实例。
   • 确保runners可用，无论是使用共享 JihuLab.com runners 还是安装新的 runners。

迁移步骤

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 社区论坛可能是一个很好的资源。