2

我们想使用持续部署。

我们有：

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

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

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

我们在业务上的时间足够长，可以编写一些脚本来执行此操作。

我的问题：

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

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

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

4

1 回答 1

2

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

回答您的问题：不，没有任何理由不与 Jenkins 一起进行部署。

优点：

  • 您已经了解 Jenkins（并且您可能知道一些怪癖）
  • 您无需引入另一种技术
  • 您说要编写由 Jenkins 调用的脚本，以便以后可以轻松切换到不同的系统。

缺点：

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

其他注意事项：

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

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

于 2013-11-12T15:17:28.333 回答