TeamCity Platform

团队导入 DevOps 的第一步:以 TeamCity 搭建 CI/CD 工作流

传统的软件组织因为将开发、IT 运营和质量保障独立在不同的部门,往往造成三个部门的各自运作,当发生错误时常彼此怪罪,不利解决问题。而现代的软件开发迭代神速,这种传统的工作方式不再符合潮流,导入精实开发、敏捷及 DevOps 等观念,将有助于团队面对日新月异的市场,拥抱变化以符合用户需求成为最重要的目标。

DevOps 范筹

为团队导入 DevOps 的第一步,除了在开发过程中撰写测试外,为团队搭建如 TeamCity 这种持续集成及持续部署服务器可说是最简单也是帮助最大的一步 。假如您还不清楚什么是持续集成、什么是持续部署?这边简单解释下:

简介持续集成(CI)与持续部署(CD)

在软件开发的过程中,需要随时确认成品是否符合需求、代码没有 Bug,所以我们会导入测试框架,甚至采用 TDD 的工作流来开发。而为了确保代码品质,团队领导往往需要品质保证(Quality Assurance)工具定期产出报表,从指标了解开发现况。在每一次发布版本前,也需要运行构建、部署、验证等工作。从以上这几点就可以知道,一个完整的软件开发流程,从写代码到部署上云,有不少工作要做,而这些工作往往是固定的、重复的、花人工及时间的、需要持续运行的。

假如这些工作都可以外包出去自动做是不是很棒?持续集成(Continuous Integration)及持续部署(Continuous Delivery)的概念就是在这样的上下文底下产生的。

换言之,CI/CD 服务器会自动监控团队的版本仓库,每当有更新(Push)时,它就会自动抓取(Pull)最新的代码运行构建、测试、产生报表、将生成的文件放进 Registry、部署至服务器。甚至,它还能帮忙运行代码风格(Coding Style)检查并修正、在测试通过后自动 Merge 分支、发送通知、监控服务器状态等。将愈多工作委托给 CI/CD 服务器,除了可以省下愈多程序员的人力成本,加上电脑不会累不会嫌枯燥的特性,大大降低了人工手动运行可能出现的错误。

以提供最优质开发工具着称的 JetBrains,在 CI/CD 这块上有没有对应的解决方案呢?

以 JetBrains TeamCity 助力开发

答案是有的!JetBrains 除了提供一流的 IDE 工具外,在团队合作解决方案上,也有 YouTrackTeamCityUpsource 三套分别对应至 Issue Tracking、CI/CD 及代码审查的工具。其中 TeamCity 就是专门用于持续集成及持续部署的服务器产品。

TeamCity 是一套服务器产品,意思是只要您有一台预安装 Java 8 的服务器,就能在该机器上使用 TeamCity。TeamCity 也支持以 Docker 容器的方式运行,若您偏好使用这种方式安装 TeamCity,记得在服务器上安装好 Docker 环境。若您不想自行搭建机器,JetBrains 目前正推出 TeamCity Cloud(Beta 版),只需要注册帐号即可立即使用。

三步即可建立 TeamCity CI/CD 工作流

在 TeamCity 里为您的项目搭建 CI/CD 工作流只需要三个简单的步骤:创建项目、配置 Build Step、运行 Build。

创建项目

无论您的代码仓库位于何处,只要创建一个项目,并配置代码仓库的 URL,TeamCity 会自动获取仓库信息。当然,您可以指定 TeamCity 使用 SSH 或 HTTPS 来连接仓库,也能上传 SSH Key 让 TeamCity 使用。

TeamCity Step1

配置 Build Step

项目创建后,TeamCity 会扫描項目代碼,自动分析项目使用的编程语言及构建所需的步骤后自动生成 Build Step。您可以依照 TeamCity 的建议套用,也可以依照需求调整。

TeamCity Step 2-1

TeamCity 支持为数众多的 Runnder,您可以依照项目特性使用不同的 Runner(如 Gradle、Maven、Ant)配置 Build Step。TeamCity 也支持 Docker 容器,无论您需要使用特定的 Docker 容器来运行构建,或是要将您的应用程式包成容器,TeamCity 都能依据需求自由组合。

TeamCity Step 2-2

您也可以通过 Build Step 配置部署动作,不论是通过 FTP/SFTP 直接上传至服务器,或是将 Docker Image 上传至 Registray,TeamCity 都能为您代劳。

运行 Build

配置好项目的 Build Step 后,只要点击 UI 右上角的 Run,TeamCity 就会依照流程运行所有动作。

TeamCity Step 3-1

TeamCity 会将每一次运行的详细日志、测试结果、报表、Artifacts 存储下来,您可以从历程纪录去了解目前的代码品质及部署结果。发生错误时,也能从这些信息调查原因,尽早修复。

TeamCity Step 3-2

若您的构建流程较复杂,或数个项目相互依赖,您也可以在 TeamCity 里创建自定义 Pipeline,甚至可以依照条件触发指定的运行路径。

TeamCity Step 3-3

只需以上三个简单的步骤,就能为团队导入 DevOps 踏出第一步。想了解完整的 TeamCity 功能特性,可以参考官网的 功能特点 页面,或转至 学习 页面取得更多学习材料。在 2020 年结束前给自己一个提升开发品质的机会,现在就导入 TeamCity 助力您的 DevOps 工作流!

免费使用 TeamCity

选择开发工具时常陷入两难:免费开源的要么功能不完整,东拼西凑的才勉强勘用。要么没有商业支持,遇到问题也求助无门。付费软件虽然好用,但每次跟领导建议采购时,总是因为要付费而被否决。

JetBrains 致力于提供最好的软件开发工具,这些工具都是因为 JetBrains 团队自己需要而搭建,通过内部千錘百鍊的测试成熟后,才演变为产品。JetBrains 团队大量依赖 TeamCity 做持续集成及部署的工作,在内部的服务器上,每天都有上百件任务透过 TeamCity 运行,确保所有代码提交都有通过测试。在一项针对内部产品团队领导的问卷调研里也指出,TeamCity 是稳定团队开发品质重要的基石。我们希望所有软件开发团队也能与我们一样高效,因此 TeamCity 提供免费使用配额,在 3 个 Build Agent 以内、100 个 Build Configuration 以下都可以无限制的享受 TeamCity 的所有功能,再也不用为了预算而委屈代码质量!

现在就下载体验

Discover more

构建链:TeamCity 的管道融合,第 2 部分 – 并行运行构建

在上一篇博客文章中,我们了解了快照依赖项以及如何将其应用于 TeamCity 中的构建链。在此博客文章中,我们描述快照依赖项如何实现并行构建。 更多快照依赖 我们之前已经开始为 demo 应用程序创建构建链。我们创建了两个构建配置:一个构建应用程序,另一个构建 Docker 映像。那测试呢? 假设有很多测试,并且依顺序运行这些测试会花费很多时间。并行执行测试组会更好。我们可以创建两个构建配置, Test1 和 Test2 ,它们将执行不同的测试组。Test1 和 Test2 都具有对 TodoImage 构建配置的快照依赖项。 由于 Test1 和 Test2 彼此不依赖,因此,如果有可用的构建代理,TeamCity 可以并行执行这些构建配置。 现在揭示了快照依赖项的新方面。使用快照依赖项,我们创建了一个构建链,该构建链实际上是 DAG – 有向无环图(Directed Acyclic Graph)。如果有足够的处理资源(即构建代理),则可以并行处理图的独立分支。 这就引出了下一个问题:我们如何触发这样的构建链?我们之前将触发器添加到 TodoImage 中,因为它是链中的最后一个构建配置。现在有两种构建配置。我们是否应该添加两个触发器 – 一个添加到 Test1 ,另一个添加到 Test2 ?虽然可以选择,但是还有一种更惯用的方法 – 使用 Composite

构建链:TeamCity 的管道融合, 第 1 部分 – 入门指南

在 TeamCity 中,当我们需要构建某些东西时,我们创建一个构建配置。构建配置包括构建步骤,并在构建代理上一次运行中执行。您可以在一个构建配置中定义任意多个构建步骤。但是,如果步骤数太大,应该检查构建配置在做什么 – 也许它一次执行太多操作。 我们可以将步骤分为多个构建配置,并使用 TeamCity 快照依赖项将配置链接到构建链。TeamCity 与构建链一起工作的方式启用了许多有趣的功能,包括构建的并行执行、重新使用构建结果以及多个源代码控制存储库的同步。但最重要的是,它使整体维护变得更加容易。在此博客文章中,我们将说明如何通过为构建配置準備快照依赖項来在 TeamCity 中创建构建链。 最小的构建链 要创建一个简单的构建链,只需创建两个构建配置并配置从一个配置到另一个的快照依赖項就足够了。在此示例中,我们使用的是 GitHub 存储库。该存储库包括一个构建 Spring Boot 应用程序的 Gradle 项目。此外,还有一个 Dockerfile 用于构建 Docker 映像。 我们将分两步构建此项目。首先,我们将构建应用程序,然后使用第一步中生成的二进制文件构建 Docker 映像。 首先,构建配置 TodoApp 会构建 Spring Boot 应用程序并发布一个工件作为结果。第二个构建配置 TodoImage ,取决于 TodoApp 构建配置并

TeamCity 2019.2 现已发布:新的清理规则、EC2 启动模板、构建链 DSL 等新功能

TeamCity 2019.2 为您提供了一些优秀的新方法来管理构建清理和监控服务器的性能。它支持 EC2 启动模板,并为定义构建链提供了新的 DSL 语法。它还提供了一种使用 Git 补丁运行个人构建的简单方法,并为实验性 UI 增加了许多改进。 增强任务清理 TeamCity 2019.2 开启了对构建创建的历史数据和工件进行控制的新维度。重新设计的清理引擎让您可以使用一系列筛选器设置不同的清理策略:例如,您可以选择保留特定分支或具有特定标记的所有构建。 我们认为,新的清理规则对项目众多的公司和开发时使用功能分支的团队来说尤其有用。 CI 概览 专业人士喜欢能够帮助他们监控任务关键型系统运行和执行的工具。从 2019.2 开始,TeamCity 会通过 HTTP 端点公开它的指标,这样就可以通过 Prometheus 擦除这些指标并通过 Prometheus Web 接口或 Grafana 仪表板加以显示。 这些指标包括服务器性能信息,以及代理、项目和构建配置的各种详细信息。 可扩展性大大提升 对于大型组织,高性能 CI 对他们的工作流至关重要。TeamCity 在多节点设置方面有所突破,让您能够在辅助服务器上将构建添加到构建列队列,管理构建问题和调查并执行其他用户级操作。 利用实验性 UI 提高效率的更多方法 开发者通常每天打开