网站海外推广技巧,古典网站素材,做公司+网站建设,电商网站是什么介绍 构建依存关系的主题既不重要也不是次要的。 各种构建工具从不同的角度处理此主题#xff0c;从而提供各种解决方案#xff0c;每种解决方案都有其优点和缺点。 熟悉发行版和快照依赖项的Maven和Gradle用户可能不了解TeamCity快照依赖项#xff0c;或者认为他们与Maven… 介绍 构建依存关系的主题既不重要也不是次要的。 各种构建工具从不同的角度处理此主题从而提供各种解决方案每种解决方案都有其优点和缺点。 熟悉发行版和快照依赖项的Maven和Gradle用户可能不了解TeamCity快照依赖项或者认为他们与Maven相关这是不正确的。 熟悉工件和快照依赖关系的TeamCity用户可能不知道除了TeamCity提供的插件之外添加Artifactory插件还使他们能够使用工件并建立依赖关系。 上面提到的某些名称似乎建立得不够充分而其他一些则可能需要讨论其使用方式。 考虑到这一点我决定在自己的博客文章中探索每种解决方案并设定了提供足够信息的目标以便人们可以选择最有效的方法。 第一篇文章探讨了 Maven快照和发行版的依赖关系。 这是第二篇文章其中介绍了TeamCity提供的工件和快照的依赖关系而第三篇也是最后一部分将介绍TeamCity Artifactory插件提供的工件和构建的依赖关系。 非Maven依赖项 虽然基于Java的Maven依赖关系管理和工件存储库在Java中非常普遍并且分布广泛但是在某些情况下您仍然可能发现它们不足或不足以满足您的需求。 首先您可能没有使用Java进行开发或者您的构建工具可能未提供与Maven存储库的内置集成就像Ant 或它的Gant和NAnt衍生产品 SCons Rake或MSBuild一样 。 其次快照Maven依赖项提供了自己的挑战这在上一篇博客文章中已涉及到这使得更难确保在构建链中使用正确的快照依赖项。 为了解决这些情况TeamCity提供了两种方法来连接相关的构建配置及其结果 工件和快照相关性。 TeamCity神器依赖项 TeamCity中工件依赖的想法非常简单在当前版本开始之前下载另一版本生成的工件。 将工件下载到指定的文件夹默认情况下为checkout目录之后您的构建脚本可以使用它们来实现其目标。 您可以在TeamCity文档中找到配置详细信息。 自然此方案不适用于具有自动依赖项管理的构建工具但它与接受或期望本地路径相对于checkout目录的构建或shell脚本一起使用时效果很好。 请注意复制不仅适用于生成的生成二进制文件而且还适用于任何类型的二进制文件或文本文件例如上面的屏幕截图所示的TeamCity覆盖率报告。 关于指定工件依赖项有一个重要的细节即“从中获取工件”配置在此配置中您应指定应从中获取文件的构建类型。 该字段的可能值为“最后成功”“完成”“固定”或“标记构建”以及构建号或“从同一链构建”。 尽管大多数值对于理解“上一次成功构建”是默认且普遍适用的选项来说应该是微不足道的但“相同链”构建的定义与TeamCity 快照依赖关系直接相关。 TeamCity快照依赖项 想象一下一个整体的多步骤构建过程构建测试打包部署您决定将其拆分为多个较小的构建依次调用它们形成执行链。 这样做可以使每个步骤分别配置或触发并并行运行某些步骤以加快流程速度例如执行测试或构建独立的组件。 最重要的是它使整体维护非常容易。 但是这样做时即使在链步骤运行的同时进行了新的提交也需要确保每个链步骤都使用从VCS提取的相同的一致源集。 这就是TeamCity 快照依赖项的目的它们将多个构建配置连接到称为执行链的单个执行链中 并且每个步骤都使用相同的源集 而与VCS更新无关。 请注意TeamCity使用术语“快照依赖关系”可能会使熟悉Maven快照依赖关系的人们感到困惑这是两个不相关的概念。 快照依赖项的配置类似于工件依赖项。 您可以在TeamCity文档中找到配置详细信息。 一起使用工件和快照依赖项 如果适用建议定义构建配置之间的两种依赖关系因为这不仅可以确保在整个链步骤中使用一致的源集而且还可以确保生成的工件始终如一。 现在上面提到的工件依赖项中的“从同一链构建”的定义变得很清楚因为这是此方案中唯一有意义的选项。 从某种意义上讲您可以考虑在获取第一个源的“快照”之后构建链步骤与VCS更新隔离地运行。 链工件可以从相同来源重新创建也可以通过与工件相关的链步骤传递。 这使得链接步骤一致可重现并且始终是最新的当应用于使用链接工件时而使用Maven快照依赖项则无法轻松实现。 TeamCity 7.0中的构建链可见性 TeamCity 7.0通过为构建链提供新的UI使构建链的步骤可见并可以重新运行从而将构建链的概念提升到了一个全新的水平。 定义快照依赖关系后新的“构建链”选项卡将出现在项目报告中以可视化方式表示所有相关的构建链并提供一种方法使用原始提取的同一组资源手动重新运行任何链步骤。 建立链触发 将构建配置与快照相关性相关联因此将其构建分组到构建链中不仅使它们在使用的源方面更加一致还影响将构建添加到构建队列的方式触发某个链步骤后默认行为是除了最初触发的步骤之外还添加所有前面的链式步骤并保持其各自的顺序。 为了更加清楚让我重复一遍 触发某些链配置会在构建队列中添加之前的配置在其左侧而不是在其后的在其右侧配置 尽管乍一看似乎是违反直觉的。 想法是标记链执行停止的位置这恰好是最初触发的配置。 它成为最后的执行步骤。 要在链配置中发现VCS更改时触发后续链步骤您可以将带有“快照依赖项更改触发”选项的VCS触发器添加到配置中这将是最后一个执行步骤。 然后只要更新任何前面的链式步骤就会触发此配置从而调度整个链式执行。 考虑到此行为因此您需要确定自动触发哪些配置以及应手动运行哪些配置。 通常VCS触发器可以自动触发对外部环境没有影响的较早的链式步骤但是在人工验证了先前的链式结果之后会手动调用最终链式步骤可能会修改外部系统。 手动运行最终链式步骤的过程通常称为“促进”先前完成的构建。 样本构建链编译测试部署 想象一下连接到构建链中的三个示例构建配置 Compile Test和Deploy Deploy是依赖于Test的快照快照依赖于Compile 。 在此示例场景中遵循上面给出的建议将自动触发Compile和Test配置而手动触发Deploy 。 Compile配置中的VCS更改仅触发该链式步骤的执行而Test配置中的VCS更改则触发Compile和Test执行按此顺序。 将Compile配置添加到构建队列后其源时间戳记将记录在服务器上以用于所有后续链式步骤。 如果将任何链式步骤连接到不同的VCS根则其源也将根据相同的时间戳拉出。 促进完成的构建 一旦自动链执行停止运行Test 您可以通过单击未触发的Deploy配置上相应的“运行”按钮来继续执行请参见上面的构建链屏幕截图。 或者可以通过其“构建操作”促进完成的Test构建并调用依赖于快照的配置-在这种情况下为Deploy配置。 摘要 本文概述了TeamCity工件和快照依赖项构建链如何触发其步骤以及如何促进完成的构建。 我希望您现在除了了解构建工具例如Maven提供的依赖关系之外还应该了解其工作原理以及何时或不适合使用TeamCity构建依赖关系。 请参考TeamCity文档以获取有关此主题的更多信息 依赖构建 建立链 该系列的最后一篇博客文章将揭示如何使用TeamCity Artifactory插件来实现类似于基于Maven的依赖管理的项目构建链的行为。 敬请关注 参考来自Goldman 博客的JCG合作伙伴 Evgeny Goldin的TeamCity构建依赖项 。 翻译自: https://www.javacodegeeks.com/2012/04/teamcity-build-dependencies.html
