我负责公司CI的实施。但现在我有个疑问。哪一个是最好的?
我是否应该为每个系统/软件创建3个杰出的工作
- 代码的构建和质量测试
- 在测试环境上构建、质量测试和部署
- 产品构建、质量测试和部署
或者最好创建下游有条件的工作，像下面这样:如何有条件地建设其他项目?
trunk将始终使用生产中的最新版本。
对于每个更改，开发人员必须从主干复制到分支，然后在代码上工作，然后调用jenkins在分支中运行以确认更改。一旦一致性完成并且没问题，开发人员将再次调用jenkins以将该代码从分支部署到生产。
正如@michaelbahr所说的[这篇文章是编辑的]我可以从工件存储库中获得最后的同源版本，但是我怎么能在jenkins从同源(测试)环境中获得包并将其移动到生产环境后自动将代码从分支复制/合并到主干?
您说您负责实施CI，我认为贵公司并没有太多的CI经验。因此，我建议两个独立的作业，而不是一个下游管道。
第一个作业应该通过提交后钩子在代码存储库中发生更改时自动触发。它构建、测试并将包部署到测试环境中。它还应该将快照包部署到像Nexus这样的工件存储库。
如果您对结果都很满意，那么您可以手动触发第二个作业，该作业从工件存储库中获取包并将其部署到生产环境中(并验证部署是否成功)。没有必要重新构建一个您已经有信心的包。
哪种方法最好取决于您的工程、测试和过程的质量。一种方法是在一个作业中完成所有三个作业(根据需要可以链接其他作业)。
例如:使用MultiJob插件和Validated Merge插件的工作流程如下:
- 开发者将代码推送到JENKINS (git push)而不是SCM仓库。Jenkins构建代码，运行单元测试，并使结果在本地可用——或者在存储库中更好。
- 额外的作业被调用(为了)来在集成环境中安装和运行构建的代码和集成测试。请注意，使用Multi Job插件可以同时在多个环境中并行运行测试。在所有测试作业成功验证后，merge将更改接受到存储库中。(如果失败，开发人员的更改不会添加到存储库中)。
- 另一个后续作业获取成功的结果并部署到生产环境中。
- 集成清理作业可以用来重置集成环境。
请注意，有一个单独的作业来执行部署到生产环境中，也允许在任何给定的时间重新部署。如果认为有问题，也可以将生产部署从自动化中分离出来。
最后，请注意，测试准确性或完整性水平的不足会导致危险的不稳定系统!