持续集成和签名二进制构建（Windows） - 最佳实践

Question

我们的应用程序是C ++ Windows应用程序。该项目在Visual Studio 2015中。

我正在帮助将构建流程迁移到云端。我们已经为我们的服务器端组件建立了一个系统，它建立在Jenkins之上。我试图尽可能地直接使用该流程，而不必为我们请求当前基础架构的例外。 （所有管道基于Jenkinsfile）。

我们在GitHub上签入时会定期运行。但是，我完全陷入困境的部分是如何处理CI环境中的签名版本，从技术上讲，每个推送到掌握的东西都可以发送。事情是服务器端组件可以工作，但对于客户端，这将签署每个单独的构建，这不是我们想要做的事情。 （我认为Windows版本不会签署构建的每个二进制文件，除非是时候发布了。）

我一直在阅读git-flow，看起来他们建议的是用版本标记版本，我们可以在Jenkins中找到它。然而，这对我来说似乎有点脆弱;我希望我们可以使用＆＃34标记提交;发布此消息＆＃34;然后它将为我设置版本等等。

换句话说，当需要发布时，如何处理Windows客户端构建的CI？你有一个关于詹金斯的按钮说'＃34;为我建立一个签名版本构建＆＃34;，或者你是否签署了每一个版本，或者你是如何做到的？我在CI / CD上读到的有关服务器构建的所有内容，但没有涉及客户端构建，尤其是涉及代码签名的构建。

Answer 1

一种可能是使用GitHub的Releases功能，该功能也有programmatic access。您可以通过两种方式使用它：

• 在GitHub中手动创建发布，然后以编程方式在jenkins（最终在专用版本中）中提取它以提取版本信息并执行签名。如果您不想使用专用版本，那么您可以检查当前SHA与最新版本的SHA之间的匹配，如果匹配，则认为它是发布版本，因此它是签名版本。
• 使用自定义脚本手动触发jenkins中的发布版本，该脚本可以计算版本号以及其他与发布相关的信息（可能更可靠，如您所说），执行签名，然后以编程方式创建GitHub版本（并且可能会推送）必要的二进制文件/资产）。