如何在持续集成/交付中管理多个环境中的多个版本？

Question

我试图绕过这个。大多数CI / CD示例/项目都有一个始终发布的主数据库，并且具有一些变体，例如： git-flow，有一个开发分支。一旦被标记，它就会被掌握。

无论哪种方式，master总是被释放到生产中。

但在我看来的现实世界中，有人类的大门可以释放到生产和其他环境中。您使用什么机制管理部署不同版本？

例如：

• v1.5是当前的生产版本
• v1.6已通过所有测试，工件准备就绪，标记为有效，但业务部门决定仅将其部署到暂存，等待部署的适当时机
• v1.5已部署到演示环境
• v2.0也通过了所有测试，但是在UAT中，受到客户的满意，因为它是主要版本

可能会有更多这样的环境 - 制作，舞台，UAT，演示，演示2等。

您使用什么机制来处理特定环境的特定版本的标记及其实际部署？

Answer 1

虽然可能有几种方法，但我使用构建管道插件https://wiki.jenkins-ci.org/display/JENKINS/Build+Pipeline+Plugin以及复制工件插件https://wiki.jenkins-ci.org/display/JENKINS/Copy+Artifact+Plugin

通过这些，您可以为每个环境创建单独的作业，并将它们完全链接起来。 因此，在您的示例中，管道将如下所示：

构建 - ＆gt;测试和部署到UAT（2.0） - ＆gt;部署到登台（1.6） - ＆gt; demo（1.5） - ＆gt; prod（1.5）

每一件都代表着jenkins的不同构造。持续集成背后的想法是你创建一次二进制文件，然后将它带到管道中，只是改变配置文件。在构建作业中，将创建工件并将其存档。在之后的任何作业中，从上游作业中拾取工件，完成一些工作，然后将其重新存档以用于下一个下游作业。因此，部署到分段将转到Test and Deploy to Uat作业以获取其二进制文件。持续交付的整个概念归结为构建管道。 http://en.wikipedia.org/wiki/Continuous_delivery（是的，我只是引用了维基百科）。

至于为特定环境标记单个二进制文件，根据定义，而不是持续集成。假设二进制文件的创建方式可以很容易地从一个环境传播到下一个环境。不幸的是，针对特定环境的单个构建永远不能是持续交付。您可以使用jenkins作为CI服务器，但如果您的流程不匹配，您将无法实现真正​​的持续集成。

在持续集成方面，精确，合并和签到似乎总是一个敏感的话题，所以我不太喜欢它。但是很多人都认为：＆＃34;如果团队的不同成员在不同的分支机构工作，那么按照定义，他们不参与持续的集成过程。＆＃34; http://eugenedvorkin.com/continuous-integration-strategies-for-branching-and-merging/

修改
对于标记特定版本，听起来您希望使用此功能：https://wiki.jenkins-ci.org/display/JENKINS/Fingerprint ...有效地完成工作，为您提供任何单个工件的整个生命周期。更复杂的解决方案是artifactory，它本质上是神器源控件。

我解释了上面部署过程的概念，如果没有关于您的特定环境的信息，则很难进一步发展。但对我来说，对于部署到tomcat容器的java应用程序，deploy插件的工作效果很好https://wiki.jenkins-ci.org/display/JENKINS/Deploy+Plugin

您不必担心选择要部署的工件。应该设置管道以始终部署在其相应的上游作业中存档的最新工件。

Answer 2

也许Docker可以帮助您解决这个问题。它能够将项目图像部署到特定环境。如果该环境具有docker客户端或docker deamon，则可以请求有关该环境以及将在其上部署的项目的特定信息。

Jenkins仍然可以在集成部分的管道中发挥重要作用，您可以让docker完成交付部分。

Docker：https://www.docker.com

jenkins的Docker插件：https://wiki.jenkins-ci.org/display/JENKINS/Docker+build+step+plugin

Docker还支持Windows机器和.NET。