【发布时间】:2017-07-17 21:31:26
【问题描述】:
我们将关注Semantic Versioning 以获取我们的网络应用程序,它看起来非常不错。现在,Jenkins 被用作 CI/CD 工具。我们希望将Octopus Deploy 用作工件存储和 CD 工具,也用于快速重新部署/回滚和其他配置功能。
Octopus 需要具有具体版本的软件包(例如:1.2.4)。因此,我们还需要对我们的 Web 应用程序进行强大的版本控制。否则,如何检测部署了哪个版本并有错误。
here 描述的解决方案不透明,并且与语义版本控制不完全匹配:
[assembly: AssemblyVersion("1.0.*")]
因为,Patch 版本应该从 0 开始一个接一个地递增,而不是从“随机”数字开始,并在 Minor 递增后重置。
在我看来 - 最好将版本存储在与包中相同的视图 (1.2.4) 中的存储库中。但我发现只有这种方式如何实现它:
- 在提交前手动增加 - 不舒服并且有风险。
- 在提交之前从 SVN/Git 挂钩自动递增 - 需要配置每个工作站。
- 从 CI 工具和提交中自动递增 - 通过 CI 监视存储库中的更改来实现循环依赖。
是否有任何其他方法可以实现与存储库中相同的版本控制,例如在 Web 应用程序的包中?或者这可能是不必要的?
2017-02-28 更新:我们发现 Jenkins 可以跳过来自特定用户或带有特定消息的提交(在高级设置中)。它解决了 CI 工具自动增量和提交的问题(CI 监控和存储库更改之间的循环依赖)。
【问题讨论】:
-
CD/CI 管道的哪一部分产生 Octopus 将使用的包?
-
持续构建后,Jenkins打包推送到Octopus,自动部署到开发环境。
-
什么运行构建?我问是因为在我们的商店中,构建定义是设置版本的地方。还;你见过 Jenkins 的 this plugin 吗?
-
如果存储库包含更改,Jenkins 会每小时自动运行一次构建。谢谢,我们将尝试查看此插件。现在,我们为版本增量实现了自定义的简单 exe 工具。
-
@gvee ,很有趣,但是这个插件破坏了我们的 Jenkins 服务器,我们需要重新安装它们 :)
标签: .net jenkins octopus-deploy semantic-versioning