暂存或生产实例? [英] Staging or Production Instance?

问题描述

服务运行时中是否有任何地方可以告诉我我当前是在暂存"还是生产"上运行?在生产环境中手动修改配置似乎有点麻烦.

Is there anywhere in the service runtime that would tell me if I'm currently running on 'Staging' or 'Production'? Manually modifying the config to and from production seems a bit cumbersome.

推荐答案

当你基于 Prod 或 Staging 时，你真的不应该改变你的配置.暂存区并非设计为质量保证"环境，而只是部署生产之前的保留区.

You should really not change your configurations when you're based upon if you're in Prod or Staging. Staging area is not designed to be a "QA" environment but only a holding-area before production is deployed.

当您上传新部署时，您将包上传到的当前部署槽将被破坏，并在上传和启动 VM 的过程中关闭 10-15 分钟.如果您直接上传到生产环境，则生产停机时间为 15 分钟.因此，发明了暂存区:您上传到暂存区，测试内容，然后单击交换"按钮，并且您的暂存环境神奇地变为生产(虚拟 IP 交换).因此，您的分期应该真正与您的制作 100% 相同.

When you upload a new deployment, current deployment slot where you upload your package to is destroyed and is down for 10-15minutes while upload and start of VM's is happening. If you upload straight into production, that's 15 minutes of production downtime. Thus, Staging area was invented: you upload to staging, test the stuff, and click "Swap" button and your Staging environment magically becomes Production (virtual IP swap). Thus, your staging should really be 100% the same as your production.

我认为您正在寻找的是 QA/测试环境?您应该使用自己的 Prod/Staging 为测试环境打开一个新服务.在这种情况下，您将需要维护多个配置文件集，每个部署环境(生产、测试​​等)一个.

What I think you're looking for is QA/testing environment? You should open up a new service for Testing environment with its own Prod/Staging. In this case, you will want to maintain multiple configuration file sets, one set per deployment environment (Production, Testing, etc.)

有很多方法可以管理发生的配置问题，尤其是在 .config 文件之上有自己的 *.cscfg 文件的 Azure.我更喜欢使用 Azure 项目的方式如下:设置一个小的 Config 项目，在那里创建与部署类型匹配的文件夹.在每个文件夹内设置 *.config &与特定部署环境匹配的 *.cscfg 文件:调试、测试、发布...这些也在 Visual Studio 中设置，作为构建目标类型.我有一个小的 xcopy 命令，在每次编译 Config 项目期间都会发生，它将所有文件从 Config 项目的 Build Target 文件夹复制到 Config 项目的根文件夹中.

There are many ways to manage configuration-hell that occurs, especially with Azure that has on top of .config files, its own *.cscfg files. The way I prefer to do it with Azure project is as follows: Setup a small Config project, create folders there that match Deployment types. Inside each folder setup sets of *.config & *.cscfg files that match to particular deployment environment: Debug, Test, Release... these are setup in Visual Studio as well , as build target types. I have a small xcopy command that occurs during every compile of the Config project that copies all the files from Build Target folder of Config project into root folder of the Config project.

然后解决方案中的每个其他项目，从 Config 项目的根文件夹链接到 .config 或 .cscfg 文件.

Then every other project in the solution, LINKS to the .config or .cscfg file from the root folder of the Config project.

瞧，我的配置神奇地自动适应每个构建配置.我还使用 .config 转换来管理发布和非发布构建目标的调试信息.

Voila, my configs magically adapt to every build configuration automatically. I also use .config transformations to manage debugging information for Release vs. non-Release build targets.

如果您已阅读所有这些内容，但仍想了解运行时的生产与暂存状态，那么:从 RoleEnvironment.DeploymentId 获取 deploymentId然后使用带有适当 X509 证书 的管理 API 来获取 Azure 服务的结构 并调用 GetDeployments 方法(它是 rest api 但有是一个抽象库).

If you've read all this and still want to get at the Production vs. Staging status at runtime, then: Get deploymentId from RoleEnvironment.DeploymentId Then use Management API with a proper X509 certificate to get at the Azure structure of your Service and call the GetDeployments method (it's rest api but there is an abstraction library).

希望能帮到你

根据要求设置配置字符串和在环境之间切换的博客文章@ http://blog.paraleap.com/blog/post/Managing-environments-in-a-distributed-Azure-or-other-基于云的 NET 解决方案

blog post as requested about the setup of configuration strings and switching between environments @ http://blog.paraleap.com/blog/post/Managing-environments-in-a-distributed-Azure-or-other-cloud-based-NET-solution

这篇关于暂存或生产实例?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！