掌握TeamCity：提升开发效率的CI/CD利器

404BrainNotFound
843 阅读8分钟

TeamCity简介

TeamCity 是由 JetBrains 开发的一款持续集成和持续交付（CI/CD）工具。它具有以下特点：

  • 跨平台支持：TeamCity 支持多种操作系统，包括 Windows、Linux 和 macOS，能够在不同平台上构建和测试项目。
  • 广泛的版本控制系统集成：支持多种版本控制系统，如 Git、Subversion、Mercurial、Perforce 等，方便与现有代码库集成。
  • 强大的构建配置：允许用户创建复杂的构建配置，支持构建步骤、触发器、构建依赖等，能够灵活地管理构建流程。
  • 并行构建：支持并行构建，能够同时处理多个构建任务，提高构建效率。
  • 实时反馈：提供实时的构建状态和测试结果反馈，帮助开发者快速发现和修复问题。
  • 插件支持：拥有丰富的插件生态系统，可以通过插件扩展 TeamCity 的功能，满足不同项目的需求。
  • 用户权限管理：提供细粒度的用户权限管理，确保项目的安全性和可控性。
  • 可视化报告：提供详细的构建和测试报告，帮助团队分析和优化构建流程。
  • 易于集成：可以与其他工具和服务（如 Docker、Kubernetes、Jira、Slack 等）无缝集成，增强项目的自动化能力。
  • 云支持：支持在云环境中运行构建代理，能够动态扩展构建资源。

安装TeamCity

在Windows上安装

前往官网下载exe安装包。

按照提示安装，端口可以选择其他端口：

建议选择外部数据库如PostgreSql，若嫌麻烦可选内部数据库HSQLDB。后续如需迁移数据库，可通过TeamCity安装目录下的bin/maintainDB脚本实现，具体可查看：数据库迁移指南

在Linux上安装

安装Java：apt install -y openjdk-21-jdk

配置环境变量：

export JAVA_HOME=/opt/jdk-21.0.1
export PATH=$JAVA_HOME/bin:$PATH
export CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar

下载并解压服务器：

wget https://download.jetbrains.com/teamcity/TeamCity-<version>.tar.gz
tar -xzf TeamCity-<version>.tar.gz
sudo mv TeamCity /opt/

启动服务：

./runAll.sh start

访问：http://localhost:8111/

创建项目

新建项目，输入仓库地址，使用密码登录或SSH密钥（此方法较为复杂）

构建项目

配置CI/CD步骤

选择使用Docker部署方案，相较于非Docker部署更具优势：

特性直接部署（非 Docker）Docker 部署
环境一致性依赖服务器环境配置容器内环境与代码完全隔离，确保一致性
依赖管理需手动安装 .NET 运行时通过 Dockerfile 定义所有依赖
部署流程需传输文件并配置服务直接推送镜像，通过命令启动容器
隔离性进程级隔离，可能受服务器其他进程影响完全容器隔离，资源可控
回滚速度需重新传输旧版本文件直接拉取旧版本镜像并重启容器
扩展性手动扩展困难可通过编排工具（如 Docker Compose）扩展

设置构建步骤：

  • docker build：使用Docker构建docker镜像，设置image name为ip:port/webdemo/demo-netcore-api:%build.number%，ip和port为harbor配置的。
  • Login Harbor：使用Commend Line登录Harbor获取权限，docker login ip:port -u admin -p Harbor12345
  • docker push：使用Docker构建命令推送docker镜像到Harbor，设置name为ip:port/webdemo/demo-netcore-api:%build.number%（与docker build阶段一致）
  • pull and start：使用SSH Exec构建命令拉取镜像到服务器并启动（由于本例teamcity和api部署在同一服务器，所以选择使用Commend Line直接执行命令
docker pull ip:port/webdemo/demo-netcore-api:%build.number%
docker stop coreapi || true && docker rm coreapi || true
docker run -d --name coreapi -p 8080:8080 ip:port/webdemo/demo-netcore-api:%build.number%

注意：

本文中harbor使用http加ip作为域名的方式，因此需要：

  • 配置docker文件，加上insecure-registries:[ip:port]
  • 推送镜像的tag格式为ip:port/project/name

运行构建：

镜像成功推送到仓库：

拉取镜像启动正常：

测试接口正常：

配置构建触发器

配置触发器VCS trigger，在Triggers页面编辑或新增VCS trigger

提交代码到代码仓库（Github、GitLab、Gitea等）

等待VCS Trigger检测到代码更改就会触发构建：

检测时间可以在此查看，并进行配置

另外可以配置VCS Post-Commit Hooks以WebHook的方式直接通知TeamCity，这样可以减轻TeamCity自行检测代码带给服务器的压力。

调用TeamCity API/app/rest/vcs-root-instances/commitHookNotification?locator=xxx

需要locator（定位器）参数告知TeamCity具体是哪个构建，可以使用buildType作为定位器

locator=buildType:WebApplication1_Build---->/app/rest/vcs-root-instances/commitHookNotification?locator=buildType:WebApplication1_Build

定位器可以包含多个维度，这允许您指定多个过滤条件。例如：

vcsRoot:(type:<TYPE>,count:99999),property:(name:<URL_PROPERTY_NAME>,value:<VCS_REPOSITORY_URL_PART>,matchType:equals,ignoreCase:true),count:9999，此定位器找到特定VCS根的所有实例。count 维度将返回实例的最大数量提高到给定值（默认限制是 100 个条目）。

测试运行WebHook：

调用失败，这里因为TeamCity的安全策略，TeamCity要求所有 REST API 调用进行身份验证。下面添加TeamCity访问令牌：

复制token

发送至 /app/rest/vcs-root-instances/commitHookNotification?locator 端点的请求并不会自动触发构建；它们只会强制 TeamCity 检查新的更改。如果需要端点请求后立刻运行构建，那么需要在Trigger中配置当检测到更改时立刻运行构建。如果没有配置或者trigger没有启用，那么新的推送会在此等待，直到有触发器触发构建：

修改VCS Trigger来实现每次check-in的时候触发构建：

同时可以设置静默期，以确保提交的原子性。

已配置Hooks的项目仍会轮询其远程存储库，作为Hooks停止工作时的备份机制。然而，每次成功的 hook 通信，轮询间隔会自动翻倍。TeamCity 将此间隔增加到的最大值是 4 小时，而最小间隔是 15 分钟。如果定时轮询揭示了没有触发提交钩子的更改，TeamCity 将会将轮询间隔重置为默认值。

在VCS Root设置中的Changes Checking项可以修改该配置：

设置构建状态发布

对于使用GitHub或者GitLab，可以使用状态发布器，它能给每个提交更新状态（success，error等）

配置代码检测

添加代码检查步骤：Inspections (ReSharper)

在检测代码前需要构建项目，在前面添加两个构建步骤

构建成功

查看检测结果：

可以根据行数定位代码问题：

配置测试报告和代码覆盖率

添加Net运行器，选择命令test并指定Code Coverage：

运行构建，在Code Coverage选项卡下查看测试覆盖率结果：

可能会有这样一个警告信息，需要我们去配置下Artifact URL

配置URL或者关闭隔离保护，再次查看结果：

可以查看每个文件的覆盖情况：

在Tests选项卡下可以查看所有的测试：

安全校验

建议分别在Git提交阶段和Build构建阶段增加审查以确保安全。

分支保护与PR审查

在 GitHub/GitLab 中设置分支保护规则：

  • 禁止直接推送到 main （主要）分支。
  • 要求 Pull Request (PR) 通过 CI 检查和至少一人审查后才能合并。

这样一来，开发项目的流程为：

  1. 克隆仓库 git clone https://gitea.example.com/your-project/api.git
  2. 保持本地 main 分支同步 git checkout main``git pull origin main # 始终从远程获取最新代码
  3. 创建新功能分支（基于 main）git checkout -b feature/user-auth # 分支命名规范：feature/[功能名]
  4. 开发与本地提交git commit -m "feat: 实现用户JWT认证逻辑"
  5. 推送分支到远程仓库git push -u origin feature/user-auth # 首次推送需要建立跟踪关系
  6. 创建 Pull Request (PR)，选择base: main ← compare: feature/user-auth，填写 PR 描述模板，关联 Issues（如有），项目等信息
  7. 代码审查
    1. 检查代码变更
    2. 提交评论或请求修改（需处理后再推送）
    3. 通过 /test 命令触发 CI 流水线
  8. 合并 PR 到 main（设置自动清理分支）
  9. 同步本地仓库，同第二步

分支命名应遵循以下规范：

  • feature/xxx # 新功能开发
  • bugfix/xxx # 问题修复
  • hotfix/xxx # 紧急修复
  • docs/xxx # 文档更新

提交信息应遵循下面规范：

  • feat: 添加用户注册功能
  • fix: 解决登录500错误
  • docs: 更新API文档
  • chore: 更新依赖版本

构建前审批

Build Approval 构建功能 允许用户通过使用审批手动控制构建的开始。此构建功能确保构建在未获得审批规则中定义的个人用户或组的批准时不会启动。对于持续集成来说，部署前审批非常重要。

Approval rules：批准规则，可以基于用户或基于用户组，如以下规则只允许在获得 teamlead 用户、 projectadmin 用户以及至少两位 QA 组成员的批准后才开始构建：

user:teamlead
user:projectadmin
group:QA:2

Timeout in配置多少时间内未批准自动取消构建。

运行构建后需要批准：

总结

TeamCity 作为一款强大的持续集成和持续交付工具，凭借其广泛的跨平台支持、灵活的构建配置和丰富的插件生态系统，成为众多开发团队的首选。它不仅能够提高构建效率，还能通过实时反馈和可视化报告帮助开发者快速定位和解决问题。无论是小型团队还是大型企业，TeamCity 都能通过其强大的集成能力和云支持，满足不同项目的自动化需求，助力团队实现高效的开发和交付流程。

avatar
文章
阅读
粉丝