连续部署：版本编号和Jenkins部署？

Question

我们希望使用连续部署。在

我们有：

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

现在应该实施这样的措施：

1. 和詹金斯一起做测试
2. 如果出现故障。站住，邮件开发者
3. 如果所有测试都正常：
4. 部署

我们有足够的时间来写一些脚本来做这件事。在

我的问题：

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

既然我们已经使用了詹金斯，我想我们是用詹金斯的脚本来做的。有什么理由用不同的（更好的）工具来做呢？在

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

Answer 1

Since we already use Jenkins, I think we do it in a script called by Jenkins. Any reason to do it with a different (better) tool?

回答你的问题：不，没有什么大理由不去部署詹金斯。在

优点：

• 你已经认识詹金斯了（你可能也知道一些怪癖）
• 你不需要再引入另一种技术
• 您说过要编写Jenkins调用的脚本，以便以后可以轻松地切换到其他系统。在

缺点：

• 可能会有更好的工具来部署
• 不能与变更控制工具联系在一起。在

其他注意事项：

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

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