TeamCity Platform 团队协作工具

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

上一篇博客文章中,我们了解了快照依赖项以及如何将其应用于 TeamCity 中的构建链。在此博客文章中,我们描述快照依赖项如何实现并行构建。

更多快照依赖

我们之前已经开始为 demo 应用程序创建构建链。我们创建了两个构建配置:一个构建应用程序,另一个构建 Docker 映像。那测试呢?

假设有很多测试,并且依顺序运行这些测试会花费很多时间。并行执行测试组会更好。我们可以创建两个构建配置, Test1  Test2 ,它们将执行不同的测试组。Test1  Test2 都具有对 TodoImage 构建配置的快照依赖项。

由于 Test1  Test2 彼此不依赖,因此,如果有可用的构建代理,TeamCity 可以并行执行这些构建配置。

现在揭示了快照依赖项的新方面。使用快照依赖项,我们创建了一个构建链,该构建链实际上是 DAG – 有向无环图(Directed Acyclic Graph)。如果有足够的处理资源(即构建代理),则可以并行处理图的独立分支。

这就引出了下一个问题:我们如何触发这样的构建链?我们之前将触发器添加到 TodoImage 中,因为它是链中的最后一个构建配置。现在有两种构建配置。我们是否应该添加两个触发器 – 一个添加到 Test1 ,另一个添加到 Test2 ?虽然可以选择,但是还有一种更惯用的方法 – 使用 Composite 类型的构建配置。

合成构建配置

合成构建配置的目的是汇总由快照依赖项组合的其他多个构建结果,并将它们放在一个位置。这种构建配置的一个非常有趣的特性是,它在执行期间不会占用构建代理。

在我们的示例中,我们可以通过快照依赖项创建依赖于 Test 1  Test2 的合成构建配置。新配置将是构建链中的最后一个配置。现在,可以将 VCS 触发器添加到该构建配置。结果是,整个构建链只有一个 VCS 触发器。

请注意,在上面的屏幕截图中,两个构建配置 Test1  Test2 并行运行。TestReport 构建配置也正在运行,但是它不占用构建代理,并且在所有构建完成后将被标记为已完成。

合成构建配置的一个不错的功能是,它还从依赖项中聚合测试结果。在我们的示例中,如果导航到 TestReport 构建配置的 “Tests” 选项卡,我们将观察在属于同一构建链的所有先前构建配置中执行的测试的列表。

小结

表面看,快照依赖看起来像一个简单的概念。但是,它启用了 TeamCity 的许多功能。在上一篇博客文章中,我们讨论了如何重用构建结果来节省构建时间和资源。在此博客文章中,我们了解到快照依赖项还可以在并行执行构建时更好地利用资源。接下来,我们将学习如何使用 TeamCity 构建链来协调部署过程。

如果您有兴趣在本地 TeamCity 实例上试用演示项目,我们已将配置上传到 GitHub 存储库.teamcity/ 目录包含我们在此博客文章中描述的构建链的 Kotlin DSL 设置。要导入这些设置,请从存储库 URL 创建一个项目。TeamCity 将在存储库中检测到 .teamcity/ 目录,并建议使用这些设置来创建项目。

原文发表于 2019 年 10 月 10 日,作者Anton Arhipov

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 的管道融合, 第 1 部分 – 入门指南

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

YouTrack 2019.3 现已发布!

请欢迎 YouTrack 2019.3! 最新版本为您 YouTrack 体验的各个方面提供了许多新功能和改进。 主要更改是性能和外观重大增强的新问题列表,包括新的边栏和工具栏、深色模式等。 此外,我们添加了用于仪表板和项目页面的问题活动源微件、Markdown 中的 HTML 支持以及其他改进以有效处理问题和附件,并与其他版本控制系统集成。 得益于社区本地化的付出和持续的努力,您现在可以使用新的语言选项,包括简体中文、希伯来语、匈牙利语和韩语。 报告改善了导航,看板开发板现在会自动添加新问题。 也添加了管理项目生命周期的新方法。 重新设计的问题列表 曾只能作为实验性功能使用,新的问题列表现已面向所有人推出! 如果要切换为深色模式,请转到个人资料图片,使用更新的可折叠侧边栏和工具栏,然后从搜索栏下方筛选问题。 您现在可以选择您想要在问题列表上看到的字段,使用操作选择命令并同时将其应用到所有问题。 该列表还更适合于适应各种屏幕和窗口大小,从而使其在设备上看起来更好。 对于仪表板和项目页面:问题活动源微件 使用这个简洁、可自定义的微件,可以跟踪您所涉及的问题和项目的最新动态。 它充当活动源,可以添加到仪表板或项目中,并且可以以多种方式使用。 个人面板 将问题活动源微件添加到您的仪表板,以实时了解项目中当前发生的情况。 选择并筛选要查看的项目、问题和更改。 基