【问题标题】:Visual studio public & web.config transforms featuresVisual Studio 公共和 web.config 转换功能
【发布时间】:2011-06-19 18:35:02
【问题描述】:

我在一家企业的开发小组工作,我们努力将业务部门及其职责分开。例如,我在开发组,我们负责与开发应用程序相关的所有任务。我们还有其他角色,例如 dbas,或我们组之外的操作角色,负责部署、服务器维护等。

我正在研究 VS 中的功能,例如发布 Web 应用程序功能和 web.config 转换功能,并在博客和其他各种地方阅读它们。根据我阅读的大部分内容,作者似乎总是假设开发人员正在管理 web 配置转换中不同环境的连接字符串、用户名、密码等内容,然后在某种生产中发布到删除服务器环境(无论是现场,还是测试或登台等)。

一个例子是here。在我们的环境中,我也假设其他环境,场景比通常描绘的要复杂一些。开发组可能不知道他们开发的任何东西部署在哪里。管理员可以根据环境特征移动服务器、数据库等并更新配置。那么在这些情况下,web.config 转换有什么帮助呢? Publish 仍然可以在本地用于为部署包构建工件,但即使您可能希望使用一些自动构建管理器。

那么发布和转换真的更适合开发和运营之间的障碍非常模糊的更基本的开发流程吗?还是我错过了什么?似乎我读过的很多关于这类事情的内容都是出于好意,但在更明确的开发过程中显得有些肤浅。

有兴趣了解其他人对此的看法和经验。

【问题讨论】:

    标签: .net asp.net iis deployment web-deployment


    【解决方案1】:

    您可以通过不同的方式使用配置转换。你说的对;您发现的大多数示例都通过一个开发人员和管理员解决了某种即时部署问题。但您也可以在更复杂的环境中将它们与 MSBUILD 一起使用。

    here

    【讨论】:

      【解决方案2】:

      我也发现了同样的问题。我的观点是,开发团队真的应该只关心靠近它的环境,这可能意味着:开发、验证测试、集成测试,也许还有一些预生产环境。

      我认为开发团队应该负责的一件事是为交付团队提供适当的应用程序安装程序,以便他们轻松部署自定义配置。这些软件包的一个重要部分是更新和避免覆盖现有配置。

      有许多产品可以简化这种开发,但我对其中任何一个都不太熟悉,尽管我听说过关于 Wix 的好消息(而且它是免费的)。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2014-04-23
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多