如何为dev / stage / production维护单独的Web服务

Question

我们希望为不同的部署步骤维护3个Web服务，但是我们如何在应用程序中定义要使用的服务？我们是否只维护了3个Web引用，并且是否以某种方式使用它们？

Answer 1

不要保持代码中的差异，而是通过配置文件。这样他们都运行相同的代码，只是使用不同的配置值（即要绑定的端口，要回答的主机名等）

Answer 2

正如其他人提到的那样，您希望将此信息存储在配置文件中。实际上，我建议为每个环境使用不同的配置文件。这将解决对每个环境进行多种设置的不可避免的问题，例如：您可能有单独的Web服务URL和Web服务端口设置，或者有一些额外的设置来处理https / security。

所有这一切，请确保您解决这些潜在问题：

如果Web服务对应用程序执行任何特别重要的操作，您可能希望将应用程序与每个环境中的Web服务结合（即在每个环境中都有一个应用程序版本）。当然，当你这样做时，对界面的任何改变都会更容易。

确保您与某个与之对话的Web服务版本显而易见。

Answer 3

我的建议是将此信息保存在应用程序的配置文件中。更好的方法是在构建过程中将给定环境的适当值注入到配置中，假设您的构建过程具有某种宏替换功能。这样，您就可以为给定环境创建目标构建，而不必在每次为不同环境构建时更改配置。

Answer 4

当我上次使用Web服务器处理项目时，我们按如下方式解决了这个问题：

• msbuild /t:deploy将构建＆amp;部署到团队部分共享的测试环境，部分特定于dev。 $(SERVER)的默认值为$(USERNAME)。
• msbuild /t:deploy /p:server=test将部署到共享测试环境，非开发人员可以查看。
• msbuild /t:deploy /p:server=live将部署到实时服务器。我想我添加了一次额外的握手，比如错误，除非你有/p:secret=foo，只是为了确保你没有意外地做到这一点。

Answer 5

所有可以从开发到测试再到prod的东西都必须是可配置的。如果您能够负担得起构建在产品安装过程中更新这些可变事物的流程 - 请执行此操作。 （将自定义添加到构建中似乎是一个低级的想法 - 最终为相同版本的源代码提供了一堆不同的不兼容构建）

Answer 6

仅供参考，昨天在这里讨论了这个问题：

How do you maintain java webapps in different staging environments?

Answer 7

将服务地址和端口放入应用程序的配置中。在服务的配置中做同样的事情可能是个好主意，至少对于端口来说，这样你的开发服务就会在正确的端口上进行监听。这样，您不必修改代码只是为了更改您正在访问的服务器/端口。

使用config而不是代码在dev，stage和production之间切换对于测试非常有价值。当您部署到生产环境时，您希望确保部署与测试完全相同的代码，而不是稍微不同。所有你应该在dev和production之间进行更改是配置。

Answer 8

使用wsdl.exe从Web服务WSDL生成代理类，而不是使用Web引用。生成的类将具有可以根据部署步骤（dev，qa，production等）设置的Url属性。