首次迁移：轻松将单个项目从 Jenkins 迁移至 TeamCity

本文由 Rajkumar Venkatasamy, draft.dev 为您呈现。

从 Jenkins 迁移可能让人感觉充满风险。你的流水线运作正常，任务如期运行，脚本将一切维系在一起。Jenkins 并没有坏，但随着时间的推移，插件泛滥、配置漂移和升级难题会悄悄消耗工程时间。

但如果有另一种选择呢？

TeamCity 用户友好的界面、内置功能以及无缝集成可以简化你的 DevOps 流程，同时减少对插件的依赖。

你不需要一次性迁移所有内容。从小处着手。移动一个独立的单一项目（一个基础构建或单元测试任务）并与 Jenkins 并行运行。这让你在不干扰现有工作流的情况下，评估 TeamCity 的内置功能、更简洁的配置以及更低的维护开销。

在本指南中，我们将逐步带你完成迁移一个项目的过程，以便你在完全过渡之前先试用 TeamCity。
比较 TeamCity 与 Jenkins

如何将单个 Jenkins 项目迁移到 TeamCity 而不破坏现有系统

在本文中，我们将逐步引导你完成迁移过程，以便你能够自信地进行复制。关键在于有条不紊的准备、谨慎的实施和彻底的验证。

要想真正从本指南中受益，最好你了解基本的 DevOps 概念，并且拥有 Jenkins/TeamCity 等 DevOps 工具的实际操作经验。

准备工作

在接触 TeamCity 之前，先清点一下你的 Jenkins 任务。这个盘点阶段非常重要，因为它能揭示那些稍后可能会绊倒你的依赖关系。

首先选择一个简单的、独立的任务。理想的候选者是一个仅包含基础构建的任务或一组单元测试，它们不受复杂的流水线或共享资源的限制。

例如，登录到你的 Jenkins 实例并导航到任务的 Configuration（配置）页面。记录所有信息：源代码仓库（例如 Git URL 和分支）、触发器（如提交时的 Webhooks 或计划任务）、环境变量以及任何构建步骤（如 Java 项目的 shell 命令或 Maven/Gradle 目标）： [LOADING...]

注意正在使用的插件。Jenkins 通常依赖插件来进行基本集成（如 Git 插件），而 TeamCity 原生处理了大部分此类功能： [LOADING...]

记录性能基线也很有帮助，例如构建运行等待时间和持续时间。这为你提供了迁移后进行对比的指标： [LOADING...]

如果你的 Jenkins 任务使用了凭据，请安全地列出它们： [LOADING...]

花 30 到 60 分钟追踪所有这些信息可以节省数小时的调试时间。

实施

当你完成了准备阶段，就可以让 TeamCity 上线了。

首先通过选择以下选项之一来设置你的 TeamCity 服务器：TeamCity Cloud 或 本地部署版。TeamCity Cloud 非常适合快速、托管的主机服务。它也非常适合测试，因为它省心且无需配置。

但是，试用期只有十四天，所以请确保你留出了测试时间。你也可以选择安装我们的本地部署版以获得完全的控制权。

创建新项目并连接你的仓库

TeamCity 设置完成后，登录 UI 并创建一个新项目。输入你的 GitHub 仓库 URL（例如 https://github.com/yourorg/yourrepo.git）并配置身份验证。根据你的仓库设置，使用访问令牌或 SSH 密钥以确保安全。TeamCity 开箱即支持主要提供商。这确保了构建会自动拉取最新代码。

TeamCity 使用 webhooks 和路径过滤器原生处理分支和变更检测，因此你无需安装或维护任何插件，即可获得更快、更可靠的触发器。 [LOADING...]

添加和自定义构建步骤

项目创建后，TeamCity 会查看你的 pom.xml 或 build.gradle 并建议下一步的 Maven 或 Gradle 构建步骤，你可以根据需要进行自定义。

然后，你可以在 TeamCity 项目的构建配置中复制 Jenkins 任务所需的构建步骤。 [LOADING...]

TeamCity 提供了众多无需插件的内置运行器。对于 Maven 构建，选择 Maven 运行器并输入如 "clean package" 的目标；对于 Gradle，选择 Gradle 运行器并以同样的方式输入你的任务。你可以在 本指南中找到有关调整运行器和添加额外选项的详细说明。

如果你的 Jenkins 步骤是通用的 shell 命令，请选择 TeamCity 的命令行运行器。与在 Jenkins 中你可能对所有事情都默认使用 "Execute shell"（执行 shell）不同——这通常会导致结构松散、难以维护的任务——TeamCity 鼓励更有条理、更易于维护的构建步骤。

如果你更偏向代码，更喜欢脚本而不是 UI 点击，TeamCity 通过 Kotlin DSL 提供了“即代码”配置。这对于受版本控制的设置很有帮助，类似于 Jenkins 的 Groovy 流水线，但具有类型安全和 IDE 支持。它允许你将配置提交到 Git，从而实现审查和回滚，这对将基础设施视为代码的团队来说非常完美。

最棒的部分是：你不必在 UI 和代码之间做出选择！你可以从 UI 开始，尝试你的构建配置，让一切正常运行，当你准备好后，点击 View as code（查看代码）。TeamCity 会根据你的 UI 设置自动生成干净、随时可提交的 Kotlin 代码。

这意味着你可以直观地学习，验证一切正常，然后零摩擦、无需重新输入即可导出为代码。 [LOADING...]

如果你想了解更多，请查看 这份关于从 Groovy DSL 转向 Kotlin DSL 的开发者指南。

设置构建触发器以实现自动化

自定义构建步骤后，配置构建触发器以自动运行。在 TeamCity 构建配置的触发器部分，添加一个 VCS 触发器用于提交时构建。这使工具能够监视你的仓库变更并启动构建。对于计划任务，使用 Schedule trigger（计划触发器）指定类似 cron 的表达式。

TeamCity 的构建触发器远不止“提交时运行”或“按计划运行”。它们包括 Finish Build Trigger（构建完成触发器）、VCS Trigger（VCS 触发器）和 Retry Build Trigger（重试构建触发器）： [LOADING...]

高级触发：无需插件链接构建

TeamCity 允许一个构建配置在满足特定条件时自动启动另一个构建配置。

在 Jenkins 中，实现相同级别的编排通常意味着安装和配置额外的插件（如 Parameterized Trigger 插件或 Pipeline: Multibranch），每个插件都会增加维护开销和潜在的版本兼容性头痛问题。

有了 TeamCity，这些功能开箱即用，因此你可以链接构建、提升制品或门控部署，而无需离开核心产品。

实时 GitHub 状态更新

TeamCity 还会立即将详细的提交状态发布回 GitHub，标记为 Passed（通过）、Failed（失败）或 In Progress（进行中），并提供指向确切构建日志的直接链接。

这种由 TeamCity 原生 GitHub 集成驱动的实时反馈循环，不需要额外的插件或 webhooks。开发人员在推送几秒钟后就能看到结果，而不是在轮询间隔或配置错误的 webhook 或插件之后等待几分钟。

管理参数和环境变量

添加构建参数和环境变量。TeamCity 支持参数和环境变量配置的模型既灵活又安全。你可以在 Parameters（参数）部分中定义参数和环境变量（无论是敏感还是非敏感变量），方法是为简单字符串选择 text（文本），为机密信息选择 password（密码）（在服务器上加密存储，绝不在日志中暴露），或为下拉选项选择 select（选择）。

例如，如果你的 Jenkins 任务使用像 APP_NAME 这样的非敏感环境变量，请创建一个值类型设置为 text（文本）的新环境变量输入参数，并输入值 Your_APP_NAME。

如果你的 Jenkins 任务使用像 DB_PASSWORD 这样的敏感环境变量，请在 TeamCity 中创建一个密码参数。你可以在步骤中将其作为 %DB_PASSWORD% 引用，或在 TeamCity 的自定义脚本中将其作为 ${DB_PASSWORD} 引用。 [LOADING...]

安全机密处理

与 Jenkins 需要单独的插件进行机密管理和保险库集成不同，TeamCity 原生支持外部保险库，如 HashiCorp Vault，使敏感数据集中化且易于审计。

这一步构建了弹性，因为参数允许轻松覆盖不同环境的变量，而无需为每个环境重写或设置构建配置。

验证和切换

一旦你在 TeamCity 中构建了项目，你需要验证它是否正常工作。首先在 TeamCity 中手动触发构建。实时观察日志；TeamCity 的界面会高亮显示错误并提供时间戳，以便你在需要时轻松观察和故障排除。将制品和结果与你的 Jenkins 基线进行比较。 [LOADING...]

如果在构建过程执行期间出现问题，常见原因可能是路径不匹配（TeamCity 的检出目录可能不同，在这种情况下，请在 VCS 设置中进行调整）或权限问题（确保代理有权访问项目使用的构建工具，如 Gradle 或 Maven）。

通常，在进行故障排除时，要系统地进行。例如，如果构建因缺少依赖变量而失败，你必须检查环境变量；如果出现身份验证错误，请验证凭据。

此外，在你的第一次迁移阶段，并行运行任务（即在测试 TeamCity 时保持 Jenkins 处于活动状态）。在两个工具中为同一提交触发构建并比较输出。这种并行运行建立了信任，并帮助你看到哪种工具实际上表现更好。

一旦验证通过（例如，在几次成功的自动触发构建后），就废弃 Jenkins 任务。首先禁用它，监视一天，然后删除。这种渐进式切换将风险降至最低，并在需要时允许你回滚。

结论

如果你跟着做下来了，你刚刚完成了将单个 Jenkins 项目迁移到 TeamCity。你已经揭开了这一过程的神秘面纱，了解了更多关于 TeamCity 直观工具的信息，并且可能发现了诸如减少插件臃肿或更卓越的机密管理等效率提升。这不仅仅是技术的交换；这是迈向 更可靠、对开发者更友好的 CI/CD 的一步。

既然你已经感到得心应手，不妨想象一下在你的整个产品组合中扩展这一规模。TeamCity 的项目层次结构和模板使其变得容易，但对于大规模迁移，规划是关键。

无论你是调整构建的开发人员还是编排工作流的 DevOps 工程师，这第一次的成功都应该给你带来信心。