问使用Jenkins进行多环境部署的最佳实践

EN

这是一个非常好的问题，因为将ci/cd工具与环境相结合是一种常见的反模式。

詹金斯是一家建筑工厂。因此，它应该完全不知道环境的概念，甚至是交付。

最佳实践是拥有某种类型的暂存过程和/或接口(如果您有能力的话:一个专用的交付软件)。

分期过程

您应该尝试为每个环境创建某种类型的暂存作业，在其中您将定义环境的配置并将最后的包捆绑在一起。

接下来，您将为每个环境提供交付作业。

传递工具

为了创建分阶段和交付作业，您可以使用非常基本的脚本工具，比如shell，但是还有一些更适合的脚本工具，如Ansible、puppet、chef.

如果您能够负担得起费用，您可以考虑投资于部署软件(我将在评论部分中提到我曾经使用过的一些软件)。

请注意，这些软件管理某种环境暂存过程。

显然，将部署软件和脚本结合起来是很有意义的。

超越了隔离工具和环境

既然您要求提供最佳实践，我认为值得一提的是另一个常见的反模式:耦合SCM工具和交付过程。

存储环境配置(当然不是密码或机密信息)并在SCM工具中运行脚本(比如svn或git.)是一个很好的实践。然而，在go live中签出环境配置和运行脚本是一种非常糟糕的做法。当你需要它的时候，它可能是不可用的。

这个退房阶段应该是我前面提到的分阶段过程的一部分。

不等式

另一个最佳实践是您的脚本应该是idempotent：这意味着您应该能够播放一次脚本来执行暂存和交付。然后，您应该能够一次又一次地播放它们，它们不会更改您的系统状态，除非配置中有某些内容。

标度

作为最后的最佳实践，我将从直接经验中分享扩展Jenkins的经验:不同的团队对Jenkins有不同的需求和使用。当太多的团队共享一个共同的Jenkins时，可能会出现资源问题。最坏的情况是团队需要重新启动Jenkins主程序，而另一个需要交付。

理想的做法是每个团队有一个Jenkins，或者每个团队拥有相同的目标和交付计划。

我刚刚从让Jenkins自由式作业和每个环境的单独作业过渡到使用Jenkins管道(声明式语法)。

在Jenkins管道中，我们只有一个文件(Jenkinsfile)，并为不同的环境定义了不同的阶段(Dev/ stages /Prod)，在这些阶段中，我们只为每个环境定义了不同的行为。例如，我们的“部署”阶段将部署到不同的kubernetes命名空间/集群，具体取决于开发环境还是暂存环境。

我喜欢这种方法，因为在所有分支中，每个项目只有一个Jenkinsfile。

对你问题的简短回答是否定的。Jenkins不需要与您的生产环境交谈，但如果您需要，它可以。换句话说，如果Jenkins能够到达这些环境，它可能会与它们交互。

根据最佳实践方法，通常我建议使用软件，使您的部署尽可能简单和可重复(例如make、Ansible、Terraform、Cloud From或Kubernetes)。

管道能够处理并行目标，这意味着如果您选择的话，您可以同时构建并部署到所有三个环境。

为了获得更多的反馈，你可能想让你的问题更精确或更详细。