持续部署:用于部署的版本编号和 Jenkins

Question

我们希望使用持续部署。

我们有：

• 本地 RhodeCode （git） 服务器中的所有源 （python）。
• 用于自动化测试的 Jenkins
• 与生产系统 （linux） 的 SSH 连接。
• 可以在一个命令中更新服务器的工具。

现在应该实现这样的事情：

1. 使用 Jenkins 运行测试
2. 如果出现故障。停止，邮件开发人员
3. 如果所有测试都正常：
4. 部署

我们在业务中有足够的时间编写一些脚本来执行此操作。

我的问题：

如何更新版本号？你可以递增它们，你可以使用时间戳...

由于我们已经使用 Jenkins，我认为我们在 Jenkins 调用的脚本中执行此操作。有什么理由使用不同的（更好的）工具来做吗？

我担心：Jenkins 成为与测试（部署）无关的事情的中央服务器。我认为应该使用其他工具，如SaltStack或Ansible。到目前为止，我们使用Fabric（ssh上方的简单层）。也许我们应该在开始持续部署之前切换到中央管理系统。

Answer 1

由于我们已经使用了 Jenkins，我认为我们在调用的脚本中执行此操作 詹金斯。有什么理由使用不同的（更好的）工具来做吗？

回答你的问题：不，没有任何大的理由不使用 Jenkins 进行部署。

优点：

• 你已经知道 Jenkins（你可能知道一些怪癖）
• 您无需引入其他技术
你
• 说你想编写 Jenkins 调用的脚本，这样以后你可以很容易地切换到不同的系统。

缺点：

• 可能有更好的部署工具
• 不能将最佳与更改控制工具联系起来。

其他注意事项：

• 不要使用同一服务器进行生产部署和持续构建/集成。这是由两个不同角色执行的两项不同任务。因此，可以采用两种不同的权限方案。
• 明智地使用权限。我对部署服务器和 CI 服务器使用两种不同的权限。我们现在有 3 台 Jenkins 服务器。
  1. CI 并部署到不受控制的环境（开发人员可以使用这些环境）
  2. 部署到受控环境。（质量保证环境及以上）
  3. 部署到具有最严格权限方案的生产（是的，这是此服务器的唯一目的）。
  4. 沙盒，实际上有第四台服务器供 Jenkins 管理员使用。
• 将可部署的工件存储在 Jenkins 之外（如果我正确阅读了您的问题，您可以这样做）。

因此，根据您现有的基础设施和程序，您可以决定使用工具。只要你在仅由 Jenkins 执行的脚本中保留尽可能多的逻辑，Jenkins 就不会登录你。