Sea*_*gen 7 build-automation build-process github jenkins
我正在尝试使用Build Flow拆分一些Jenkins工作插件,这样我们就有三个"起点",而不是三个"起点",然后使用DSL来触发下游作业.我在Build Pipeline插件上选择了Build Flow,因为在不同的管道之间共享作业似乎要困难得多(即,用一个编译作业共享多个启动作业的工作区).
以前,我设置了三个工作:Project-PR,Project-DEV和Project-PROD.
只要在GitHub中发生拉取请求,Project-PR就会构建,并且只会运行我们单元测试的较小子集,这样我们就可以快速验证PR是否可以合并.
只要将功能分支在GitHub中合并到主开发分支中,Project-DEV就会构建,并且可以手动触发并给予不同的分支.它将运行整套装置 - 基本上是一个完整性检查,一切都很好.然后它将编译和缩小,并推送到QA环境进行测试,然后它将针对该QA环境运行全套集成测试.此步骤配置为参数化构建,参数是要拉,测试和推送的分支的名称.它将推动并设置特定于该分支的QA环境,以便我们可以QA多个功能而无需合并到开发(即feature-one.qa.example.com,feature-two.qa.example.com) .
Project-PROD只能手动触发,并且可以完成整个单元和集成测试套件,编译和缩小前端代码(Less,JS和CSS),并将构建的代码推送到一个特殊的"发布分支"然后可以在GitHub中部署 - 我们还没有达到Jenkins负责部署的程度.
现在,我想要设置的是将子任务分成他们自己的工作,这样就可以轻松地设置新的工作而无需复制和粘贴所有构建步骤(或复制工作并更改所有工作需要独特的事情).这可以让我们做一些事情,比如创建Project-DEV的副本,但是为一个部署到云中设置的暂存环境的作业切换上一个作业.或者轻松创建可以将测试结果报告给第三方源的作业,即将结果复制到共享网络文件夹或其他内容.或任何数量的东西.目标基本上是使用这些子任务作为构建块来让我们构建更复杂的作业,同时还可以更容易地更新构建的一部分如何工作(例如,我们可能切换到不同的编译技术,
例如,Project-PR将分为以下几种:
Project-PULL -> Project-SetupBuildEnv -> Project-PartialUnitTests
(BuildFlow) (Normal Job) (Normal Job)
SetupBuildEnv只会提取任何NPM或Composer要求,并设置测试和构建所需的目录.然后运行PartialUnitTests,并将其结果报告给
Project-DEV可以像这样分开:
Project-DEV -> Project->SetupBuildEnv -> Project-FullUnitTests -> Project-Compile -> Project-Minify -> Project-DeployQA -> Project-FullIntegrationTests
这样,共享的构建过程的部分(在本例中为Project-SetupBuildEnv)可以在作业之间轻松共享,减少重复,并且更容易更新构建过程中的步骤,而无需记住每个作业使用那一步.
现在,我正在使用 共享工作区插件,以便所有步骤使用相同的工作区.但是,我遇到了一个问题:它实际上并没有使用一个工作区.发生的事情是Build Flow作业将获得一个目录(例如:/ sharedspace/shared_one),并将代码从GitHub下载到那里.然后它将触发DSL,启动'SetupBuildEnv'作业.但是它不是在同一个目录中工作,而是获得一个名为"/ sharedspace/shared_one @ 2"的目录,并在那里运行构建设置任务.然后当它进行第三步(单元测试)时,它失败了,因为现在它有第三个目录(/ sharedspace/shared_one @ 3),但是该目录没有设置运行,所以所需的节点和组合器模块丢失了.什么'
问题时间:
根据我的经验，即使你确实做到了这一点，这也可能不是一种长期可扩展的方式。我们发现共享工作区插件对于长时间/复杂的构建来说完全是一个坏主意（与您的原因类似 - 但也：跨数十个从站的扩展突然变得困难）。可以说，这个想法有点违背现代可扩展 CI 的精神。
相反，我会将更多的工作委托给您的构建工具，无论是 Maven / Gradle、Ant，甚至是 Grunt，等等。如果您想让这些构建真正模块化，但无法在每个步骤中进行重建（我们认为完全独立值得每个构建浪费几分钟），那么也许可以考虑在关键阶段创建有用的工件 - 在您的情况下，缩小资产 TAR、库 JAR、或者可能是webjar等，并将它们部署到（Maven？）存储库。
管道中的后续构建步骤可以快速、轻松且可重复地从此集中存储库中提取最新（或命名版本）资产，并继续构建过程。
另一种选择（具有相似之处）是构建一个或多个资产，但仅在运行越来越多的测试后才升级它们，这可以在由构建流程协调的单独构建中完成，使用升级构建插件等。