Question

我正在创建Jenkins管道来构建和部署我们的应用程序。我希望为登台和生产环境提供相同的构建（buld-once-deploy-many方法）。

将功能分支合并到staging分支将为分段和生产构建应用程序，但它只会将其部署到staging存储桶。

经过测试，开发人员将staging分支合并到master并将之前的staging构建并将其部署到生产中是件好事。

替代方案是拥有一个分支，开发人员将手动触发Jenkins上的另一个作业，该作业将构建部署到生产中。我想避免开发人员进入jenkins并触发构建，因为他们中的大多数人发现它令人生畏，还有一些令人讨厌的vpn配置步骤，他们需要通过它来访问Jenkins等。

这会是一种不好的做法吗？你对如何实现这样的事情有什么建议吗？

由于

Answer 1

这比Jenkins的问题更像是一个devops问题，但这是我的看法......

我无法决定您是说要从主分支重新构建，还是仅使用对主分支的提交来触发原始分段工件的部署。所以我将解决这两个问题。

对于这种情况：

如果您在暂存分支中构建工件，并对其进行测试。在测试中，一切看起来都很绿。因此，您将这些更改合并到另一个分支，重新构建并部署到生产。

问题：您是否 100％确定主分支中没有其他内容与在分段中构建和测试的内容没有什么不同？

您冒着jello视图反模式的风险，因为未知和未经测试的更改可能潜入您的生产工件中。很难解决为什么它在分期时工作得很好，但现在生产失败了。

对于第二种情况：

如果你说你不会从主分支重建，那么合并回主人并不会为你买任何东西，除了触发新的构建，因为你永远不会生成一个工件来自师父。

如果您打算采用这种方式，我认为您可以提交一个分支，然后标记要用于生产的版本，然后触发标记。

无论哪种方式，这似乎都是一种奇怪的模式，并且很难在Jenkins中以自动化方式完成。不知何故，新触发的构建必须找到先前构建的工件并将其部署到生产中。

可能的解决方案：

有几种方法可以解决这个问题，但最简单的方法之一是构建一次并在整个生产线上部署相同的工件，正如您提到的替代选项。但这可能需要一些批准或Jenkins的额外触发。

如果您不希望开发人员接触Jenkins，那么更有可能的解决方案是在暂存环境中构建和运行您的单元测试和冒烟测试。然后，当开发人员想要将构建升级到生产时，他们将其提交到主分支，其中相同的构建启动，并且除了更高级的集成，功能和验收测试之外，还会再次执行测试。如果它没有通过，它就不会进入生产阶段。

您在初级阶段的初步测试可以为开发人员提供快速反馈，但不能作为官方测试，只能在生产版本上运行。

使用管道脚本，您可以使用单个Jenkins文件和单个多分支管道作业轻松完成此操作，其中阶段仅在分支模式匹配时运行。

stage ("Acceptance Testing" ) {
    when { branch "master" }
    echo "Do testing here"
}