c# 编译器指令在持续交付管道中使用

Posted

技术标签:

【中文标题】c# 编译器指令在持续交付管道中使用【英文标题】:c# compiler directives use in a continuous delivery pipeline 【发布时间】:2016-02-05 22:05:59 【问题描述】:

我的团队使用编译器指令为不同阶段(调试、测试、发布)创建不同版本的产品,但现在我们想要移动 CI/CD 策略,并且我们正在讨论使用编译器指令是否是个好主意因为为一种配置生成的工件不能用于另一种配置,例如,我们的 CI 服务器使用 test 配置运行构建过程,并且构建过程的所有阶段都通过,包括 UI 自动化测试,在此过程中创建的工件无法部署到生产环境,因为对于生产应用程序需要使用 release 配置进行编译,从而创建一组新的未经测试的工件来部署生产环境,其中我的观点是,前一阶段执行的工作已经过时,因为您可能希望针对新创建的工件运行测试。

有没有人遇到过类似的情况,如果有,您是如何与您的团队一起解决的。当您想要迁移到 CI/CD 策略时,使用 c# 编译器指令是个好主意吗?

【问题讨论】:

【参考方案1】:

两年前我们也遇到过类似的问题。我们正在为每个环境(DEV、QA、MOCK、PROD)重新构建我们的代码,并且在某些情况下,环境之间会发生签入并使我们的所有测试无效。当我们开始 CD 之旅时,我们知道我们必须实现一次构建/多次部署的场景。我们使用 MSDeploy 来部署我们所有的代码。这包括网站/服务、Windows 服务、计划任务和 SQL 数据库。

我们将所有环境差异放在我们的配置文件中,并通过Parameterization in MSDeploy 控制转换。在部署时应用参数化。安装程序由定义需要参数化的内容的 parameters.xml 文件和每个环境的 SetParameters.[environment].xml 文件以及该环境的相关值组成。

【讨论】:

感谢您的信息。我会研究这种方法。

以上是关于c# 编译器指令在持续交付管道中使用的主要内容,如果未能解决你的问题,请参考以下文章

如何将跨微服务的端到端测试包含到多个持续交付管道中?

SemVer 对于持续交付来说是多余的吗?

java面试之jenkins

如何在持续交付的发布后自动化主合并

从持续集成到持续交付——Docker Cloud概览

持续交付1-持续交付