持续部署：版本编号和Jenkins用于部署？

Question

我们希望使用持续部署。

我们有：

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

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

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

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

我的问题：

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

由于我们已经使用了Jenkins，我认为我们是在Jenkins调用的脚本中完成的。有没有理由用不同的（更好的）工具做到这一点？

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

Answer 1

  

由于我们已经使用了Jenkins，我认为我们是在一个名为by的脚本中完成的   詹金斯。有没有理由用不同的（更好的）工具做到这一点？

回答你的问题：不，没有任何重要理由不与Jenkins一起部署。

优点：

• 你已经认识詹金斯了（你可能知道一些怪癖）
• 您无需介绍其他技术
• 您说要编写Jenkins调用的脚本，以便以后可以轻松切换到其他系统。

缺点：

• 可能有更好的工具可用于部署
• 不能与变更控制工具结合得最好。

其他注意事项：

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

因此，根据您现有的基础架构和程序，您决定使用工具。只要您在只由Jenkins执行的脚本中保留尽可能多的逻辑，Jenkins就不会让您登录。<​​/ p>