TeamCity Platform 团队协作工具

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 提高效率的更多方法

开发者通常每天打开 TeamCity 很多次,这就是为什么我们要设计一个地方,让他们能够在这里快速找到所需的内容,无论项目有多大和多复杂。按照 TeamCity UI 路线图,我们引入了一个新的构建页面,让您可以轻松地浏览构建历史,调查问题并发现构建链中的任何错误配置或瓶颈。

查看实验性 UI – 现在的外观令我们十分欣慰。

EC2 启动模板,将构建提升到新高度

我们希望 TeamCity 能够为您提供在现代工作流中所需的一切功能。版本 2019.2 添加了对 EC2 启动模板的支持,并让您能够从 AWS 帐户使用启动参数运行云构建代理。使用启动模板,在构建代理上更新和安装新软件将变得十分简单,您无需在 TeamCity 项目配置中更改任何内容。

改进 DSL

轻松构建构建链

Goodbye clicking, hello scripting.Kotlin DSL 现在为定义构建链提供了一种简单且非常直接的语法。设置顺序和并行构建,配置失败条件和依赖项并将所有内容存储为代码。

众多参数,一个模板

项目配置变得更加简单。从 2019.2 开始,您的 Kotlin DSL 配置可能会包含自定义参数,您可以稍后在 UI 中导入项目时定义这些参数。

运行更多任务,更少等待时间。使用 Git 补丁开始构建。

通过创建 Git 补丁、将它上传到 TeamCity 并运行个人构建来快速测试您的变更 – 无需创建任何分支或提交任何内容。

如需查看版本 2019.2 中的变更完整列表,请参阅 TeamCity 文档

立即下载 TeamCity 2019.2

请在安装新版本前查看升级说明,及时在我们的跟踪器报告任何问题,或通过我们的官方微信以及论坛提出问题。

Discover more

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

传统的软件组织因为将开发、IT 运营和质量保障独立在不同的部门,往往造成三个部门的各自运作,当发生错误时常彼此怪罪,不利解决问题。而现代的软件开发迭代神速,这种传统的工作方式不再符合潮流,导入精实开发、敏捷及 DevOps 等观念,将有助于团队面对日新月异的市场,拥抱变化以符合用户需求成为最重要的目标。 为团队导入 DevOps 的第一步,除了在开发过程中撰写测试外,为团队搭建如 TeamCity 这种持续集成及持续部署服务器可说是最简单也是帮助最大的一步 。假如您还不清楚什么是持续集成、什么是持续部署?这边简单解释下: 简介持续集成(CI)与持续部署(CD) 在软件开发的过程中,需要随时确认成品是否符合需求、代码没有 Bug,所以我们会导入测试框架,甚至采用 TDD 的工作流来开发。而为了确保代码品质,团队领导往往需要品质保证(Quality Assurance)工具定期产出报表,从指标了解开发现况。在每一次发布版本前,也需要运行构建、部署、验证等工作。从以上这几点就可以知道,一个完整的软件开发流程,从写代码到部署上云,有不少工作要做,而这些工作往往是固定的、重复的、花人工及时间的、需要持续运行的。 假如这些工作都可以外包出去自动做是不是很棒?持续集成(Continuous Integration)及持续部署(Continuous Delivery)的概念就是在这样的上下文底下

Space 中的项目管理

我们推出了 Space 的目的是为了创建一个新的集成的团队环境。 使用多种工具使跟踪项目、团队和人员的所有事情变得更困难。 Space 致力于将我们的工作和交流全部集中在一个地方,而不是将其分散在各种工具上。 Space 结合了用于软件开发、协作、计划、分析和项目管理的工具。它还包含文档、知识库和公司结构 – 全部集中在一个界面中,对技术人员而言功能强大,并且对每个人都易于使用。 程序员、设计师、质量保证(QA),产品市场经理(PMM)、人力资源(HR) 和经理都轻松地使用,可以在项目上无缝协作。 这就是 Space 背后的想法以及我们的主要目的。 今天,我们想向您介绍我们的项目管理概念。 这是目前的计划,是项目管理流程背后的想法,并且仍在进行中。 不过,我们很想听听您对此的想法,以确保我们朝着正确的方向前进。 Space 的项目管理概念 整个项目管理过程可以分为三个主要阶段:计划、分析和执行。 结合这些阶段,我们旨在支持各种各样的工作流程。 有时,您可能会想要从头开始进行计划阶段,然后平稳地进入分析和执行阶段。 其他时候,您或许想从执行阶段返回到计划,例如当功能需要利益相关者的更多输入或需要其他分析时。 I. 计划 项目经理通常使用简单文档 / 笔记格式的分层清单,以汇总讨论结果、创建思维导图、分解项目范围并将并将构想组织成计划。 我们决定在 Space

构建链: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 构建配置并