Jenkins 是 DevOps 领域里非常好的 CI/CD 工具，它凭借其独特的功能，几乎可以满足你一切的的业务要求。其中一个独特的功能是多分支流水线(Multi-branch 流水线)，可以动态配置流水线。但是，随着公司的发展，单独的多分支流水线并不能完全满足你的所有需求，特别是在涉及大型企业时，你需要考虑流水线的集中管理，治理，稳定性，限制和安全性等其他事项。因此对于具有 Jenkins 流水线的大规模 CI/CD 环境，你需要添加之前没有想到的更多功能。
动态配置流水线#
当一个开发人员创建一个新分支并将其推送到远程代码仓库时，Jenkins 会为这个新分支动态创建流水线。根据代码仓库，甚至也可以作为动态创建 Pull Request 流水线。这个动态功能在使用 Feature 分支或其他类似功能的团队中非常有用，由于本文的主题不是多分支流水线，你可以在端到端多分支流水线项目创建中找到详细信息和一些示例。
流水线即代码#
在多分支流水线中，脚本存储在项目代码仓库中，这就是“流水线即代码”的概念。此外，当你拥有小型开发人员团队或项目没有大量分支时，它非常有用。这样，开发人员可以根据需要更改流水线，将更改推送到分支，并立即看到更改生效，但对于拥有数百或数千名拥有大量项目的开发人员的大型企业而言，这种方案就完成不可行了。
集中式库#
当你的团队或项目增加时，是时候考虑一种方法，比如通过共享的的方式应该在所有项目中。从长远来看，这种“集中式库”变得非常关键，因为随着规模的扩大，流水线中出现了新的要求或变化，在这种情况下，手动更改每个流水线或脚本对管理员来说将是一场噩梦。因此，如果你在一个地方进行更改并且每个流水线都得到更新，那么拥有该集中式库将更加实用。这是 Jenkins 共享库概念的用武之地。有关详细信息，你可以访问该站点。
即使你只有一个流水线，仍然可以使用集中式库。
治理与稳定#
如果你的团队有对 CI/CD 一定了解的开发人员，并且你确信他们不会做出重大更改或编写脚本错误导致影响环境的稳定性，那么将流水线脚本放在代码中是很好的。但是，你真的确定吗？
有人很可能会意外删除流水线文件或者可能出现小错误，这些小错误都会影响 CI/CD 的稳定性。如果你在早期发现这些错误时很容易解决这些错误，如果没有，这些微小的变化或错误将可能比你想象的更严重的影响 CI/CD，它将被传播到不同项目中的所有分支或 tag，这会变得很难解决。
你需要将正确的流水线脚本推送到所有分支和/或代码仓库，或是要求每个开发人员提取最新的脚本，这种类型的问题集中式库这种更高级的方式来解决，除此之外，你的环境会因为有人可能会删除 Jenkins 文件或输入一些拼写错误带来风险。
远程文件插件#
为了消除不必要的更改的风险并降低使用的库的复杂性，我们需要以某种方式将流水线脚本与项目/代码代码仓库分开，同时仍继续使用多分支流水线功能。为此，我们有远程文件插件。
这个插件使多分支流水线能够从其他代码仓库运行/加载流水线脚本，而不是将它们放在项目/代码代码仓库中，通过这个功能，你可以拥有一个单独的代码仓库，你可以在其中放置所有流水线脚本，并且只能为你自己提供访问权限。这样，你将拥有与集中式库相同的集中式流水线脚本代码仓库。此外，你可以将流水线脚本存储在集中式库本身中。
这个功能的好处是除了有访问权限的人之外，没有人能够在流水线脚本中进行更改。你在集中流水线脚本中所做的任何更改都将影响使用该脚本文件的所有多分支流水线。这样，你无需等待所有开发人员获取更新版本或将脚本推送到所有代码仓库上的所有分支。
另一个好处是，如果你将集中式流水线脚本放入 BitBucket 或 GitHub 等代码仓库中，你还将拥有代码审查功能。这样，你可以与其他人共享代码仓库，同时仍可限制或查看其他人所做的更改。
结论#
在大型企业中创建 CI/CD 流水线并不容易，你需要考虑治理，限制，稳定性和安全性等概念。在此上下文中，借助 Jenkins 的其他功能，Remote File Plugin 提供了一个独特的功能，用于集中，维护和共享流水线脚本。
有关插件的详细信息，你可以访问插件的 Wiki 页面。