首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >有没有专门针对.NET/TFS环境进行调整的十二要素应用程序的示例?

有没有专门针对.NET/TFS环境进行调整的十二要素应用程序的示例?
EN

Stack Overflow用户
提问于 2012-06-18 23:47:52
回答 4查看 4.7K关注 0票数 12

有一篇名为“十二要素应用程序”(http://www.12factor.net/)的优秀文档,其中作者试图定义设计、构建和部署现代应用程序即服务的完美方法。

该文档非常笼统,在许多情况下,所描述的实践并不是最佳的,不容易实现,或者与Microsoft的最佳实践相冲突。该文档不鼓励使用配置文件,而是使用环境变量进行配置。这在常见的.NET中似乎是不正确的(最好?)练习使用XML配置文件。

在理想的情况下(即忘记预算/技术/技能限制),在一个组织中,所有部署都选择Microsoft平台作为首选平台,选择.NET/TFS作为开发环境/工具,如何遵循十二要素应用程序中的指导?

有没有这样的应用程序的好例子(也许是一个开源的,有一个很好的参考架构的应用程序)?

EN

回答 4

Stack Overflow用户

发布于 2012-06-23 06:05:02

我读过关于配置的部分,作者显然不理解.NET中配置文件的用法,他们表达的问题是我们过去在.ini文件中遇到的问题。.NET不存在这些问题,因为:

  1. “桌面”应用程序在每个部署中都有一个配置文件。"app.config“将作为部署到与web应用程序的application.
  2. In相同的文件夹中的program.exe.config而存在,web.config文件的层次结构将再次存在于明确定义的位置,并且具有明确定义的名称。
  3. Visual Studio2010中的web.config转换功能允许将主配置文件以及指定如何自动编辑每个构建配置(环境)的主文件的转换文件签入到源代码管理中。所有这些文件都可以存储在源代码管理中。
  4. 虽然默认将凭据存储在此类文件中(因此签入到源代码管理中),但这不是必需的。
  5. 至少在web应用程序的情况下,IIS功能以及Visual Studio2010的Web发布管道允许对部署进行参数化。默认情况下,这包括连接字符串的参数化,这是可能出现凭据的主要区域之一。这可以扩展到包括所有凭据或其他敏感数据的参数化,以便开发人员无法访问此信息。这些参数可以作为部署过程的一部分进行填写。
票数 12
EN

Stack Overflow用户

发布于 2012-06-29 02:23:39

  1. 不要将配置存储在代码中
  2. 不要将您的配置放在源代码控制中(或以可能最终在源代码控制中结束的格式)。他们想要“单一代码库”。
  3. 将您的配置设置为任何技术堆栈都可以访问的格式(.NET/Java/Ruby/.等)。

我想说,.NET配置文件符合其中的一半。

  1. 配置文件不是代码形式(通过)。
  2. 配置文件不一定要在源代码控制中,但它们通常会在那里结束(失败)。
  3. 尽管.NET配置文件是XML格式的,并且可以被其他技术访问,但是它有很多.NETisms。配置部分的模式是由.NET类型提供的,因此Java应用程序无法验证该模式。(half-credit).

虽然我可以同意他们的要求的意图,但我认为他们关于环境变量的建议是一个糟糕的建议。他们之所以选择环境变量,是因为他们认为环境变量是最小的公分母,并且在所有平台上都可用,但它们实际上并不是在所有平台上都可用。如果您运行的是部分信任的web应用程序(在共享主机平台上很常见),则可能无法获取/设置环境变量。

环境变量是按机器设置的。如果我必须对我的生产环境进行配置更改,我希望在一个地方对所有服务器进行一次更改。环境变量不允许您这样做。

虽然我能理解他们的观点,但你不希望将秘密存储在所有开发人员都可以访问的版本控制中。对配置进行版本控制肯定有好处。当您的生产环境由于配置更改而停机时,很容易就会问。“什么改变了”?某人只是通过ssh连接到一台prod机器并设置了一个环境变量,留下的审计跟踪可能不那么容易跟踪。话虽如此,我通常不会将配置文件存储在与其余代码相同的版本控制部分中。我把它们放在一个有安全限制的文件夹中,这样只有必要的人才能访问。可以想象,您可以更进一步,将它们放在不同的项目中。

例如。他们主页上的第一个要点是“使用声明性格式进行自动化设置,以最大限度地减少加入项目的新开发人员的时间和成本”;我敢打赌,所有那些不应该在任何地方的文件中的配置设置都在厨师的菜谱中。如果有人花了很长时间来获得正确的厨师食谱,而没有将其存储在某个版本控制中,我会感到惊讶。

我认为他们可以以不同的方式编写配置页面,只要求将您的配置与代码分开。将其保存在单独的文件中(不要将其嵌入到代码中),并将其单独存储在某个地方(不要将其放在同一存储库中)。您的部署过程将把这些(代码和配置)重新组合到一个可部署的包中,但在此之前,它们应该是分开的。

我对配置的建议是将配置视为“附加资源”,并将其存储在后备存储(数据库)中。

票数 7
EN

Stack Overflow用户

发布于 2012-06-29 09:55:11

设计中有很多问题,我觉得有点幼稚。

例如,在Backing部分中,他们指出您应该能够在不考虑代码更改的情况下换出数据存储。

问题是,为了利用任何特定数据存储的性能和功能优势,您将自然而然地倾向于利用您开始使用的存储的特定功能。

此外,并不是每个数据存储都支持一组通用的命令,以便您可以轻松地从一个命令移动到另一个命令。您不能只是将表结构直接应用于CouchDB,然后期望向其抛出SQL命令。

这意味着您必须放置一个前端,以便从本质上用一组公开为web服务的命令来包装每个特定的数据存储……imho,这使得开发变得更加困难,而带来的好处却很少(如果有的话)。

现在,如果他们将其限制为将类似的服务器(本地mysql)交换到远程服务器(Amazon RDS),那么通过url访问数据存储资源的要求就无关紧要了。此外,没有必要要求该移动不发生代码更改,因为您不应该仅仅为了支持在不同服务器上运行完全相同的数据库而更改代码。

以上只是我诚实地看过的第一个领域。正如John Saunders所说,config one也显示出对.Net等技术的完全缺乏理解。

票数 5
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/11086388

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档