我正在努力解决这个问题。大多数 CI/CD 示例/项目都有一个始终发布的主控，并且有一些变体，例如git-flow，有一个开发分支。标记后，它会转到 master。
不管怎样，master 总是发布到生产环境中。
但在我所见的现实世界中，存在用于发布到生产环境和其他环境的人工闸门。您使用什么机制管理不同版本的部署？
例如：
可能还有更多这样的环境 - 生产、登台、UAT、演示、demo2 等。
你使用什么机制来处理特定环境的特定版本的标记，以及它的实际部署？
【问题讨论】：
标签： jenkins continuous-integration continuous-deployment
虽然可能有几种方法可以做到，但我使用构建管道插件https://wiki.jenkins-ci.org/display/JENKINS/Build+Pipeline+Plugin 以及复制工件插件https://wiki.jenkins-ci.org/display/JENKINS/Copy+Artifact+Plugin
借助这些，您可以为环境的每个部分创建单独的作业，并将它们完全链接起来。 因此，在您的示例中，管道如下所示：
构建 -> 测试并部署到 UAT (2.0) -> 部署到 staging(1.6) -> 演示(1.5) -> prod (1.5)
每个部分都代表 jenkins 中的不同构建。持续集成背后的想法是您创建一次二进制文件，然后将其沿管道传输，只在此过程中更改配置部分。在构建作业中，工件被创建然后存档。在之后的任何作业中，从上游作业中提取工件，完成一些工作，然后将其重新存档以用于下一个下游作业。因此，部署到登台将转到测试和部署到 Uat 作业以获取其二进制文件。持续交付的整个概念归结为构建管道。 http://en.wikipedia.org/wiki/Continuous_delivery（是的，我只是引用了维基百科）。
至于为特定环境标记单个二进制文件，这是根据定义，而不是持续集成。假设二进制文件的创建方式可以很容易地从一个环境传播到下一个环境。所以不幸的是，针对特定环境的单独构建永远不可能是持续交付。你可以随心所欲地使用 jenkins 作为 CI 服务器，但如果你的流程不匹配，你将永远无法实现真正的持续集成。
在涉及持续集成时，分支、合并和签入似乎总是一个敏感的主题，所以我不会过多讨论。但是很多人都有这样的想法：“如果团队的不同成员在不同的分支上工作，那么根据定义，他们就不会参与持续集成过程。” http://eugenedvorkin.com/continuous-integration-strategies-for-branching-and-merging/
编辑
对于标记特定构建，听起来您希望使用此功能：https://wiki.jenkins-ci.org/display/JENKINS/Fingerprint ... 它可以有效地完成工作，为您提供任何单个工件的整个生命周期。更复杂一点的解决方案是工件，它本质上是工件源代码控制。
我在上面解释了部署过程的概念，如果没有有关您的特定环境的信息，很难更进一步。但对我来说，对于部署到 tomcat 容器的 java 应用程序，deploy 插件效果很好https://wiki.jenkins-ci.org/display/JENKINS/Deploy+Plugin
您不必担心选择要部署的工件。管道应设置为始终部署在其相应上游作业中存档的最新工件。
【讨论】：
也许 Docker 可以帮助您解决这个问题。它能够将项目映像部署到特定环境。如果该环境具有 docker 客户端或 docker 守护程序，您可以请求有关该环境和（将）部署在其上的项目的特定信息。
Jenkins 仍然可以在集成部分的管道中发挥重要作用，您可以让 docker 完成交付部分。
jenkins 的 Docker 插件：https://wiki.jenkins-ci.org/display/JENKINS/Docker+build+step+plugin
Docker 还支持 windows 机器和 .NET。
【讨论】：