5

我们公司正接近其“上线”日期（以及获得 QA 部门日期），我正在尝试定义正确的运营流程来支持这一点。我的一个重要考虑是如何避免不可避免地发生的部署/配置地狱。你们有没有找到一个很好的解决方案来将构建移交给非程序员，以便他们可以在 QA、登台和生产环境中成功安装和配置它？

对我们来说，一个完整的环境由异构计划任务、Windows 服务和网站的混合组成，所有这些都可以通过并行部署进行横向扩展。值得庆幸的是，配置方式是一致的。不幸的是，这一切都是通过 .NET web/app.config 文件进行管理的。根据我的经验，QA 和运维人员在尝试修改它们时总是搞砸（XML 对大多数人来说难以处理！）

这是我正在考虑的选项：

使用 machine.config 文件

这是我在实践中没有做过的事情，但看起来很有希望。如果我们创建一个 machine.config 模板，其中包含可能因环境而异的每个应用程序的每个设置，这将允许管理员对一个文件进行所有更改并将其部署到环境中的每台机器上。

优点：
这可能会减少部署系统所需的步骤数量
缺点：
必须以某种方式记录配置架构更改
未知数：
我们使用自定义配置部分和其他引用程序集的配置扩展。这是否需要我们在机器的 GAC 中安装我们的 .NET 程序集？

在构建过程中执行配置文件操作

如果我们设置 QA、登台和生产环境，使它们看起来与我们的软件（虚拟服务器和 LAN 等）相同，那么 QA 应该能够将无需更改配置的现成软件直接转换到登台环境，并登台到生产环境. 有了这个设置，理论上我们可以交给 QA 预先配置的 foo.config 文件，没有人需要接触。

优点：
工程将更擅长确保配置文件有效
缺点：
工程师意识到生产配置可能被认为是糟糕的安全实践（一个糟糕的论点，恕我直言）

拥有一个网络集中的设置存储库

这个看起来对我没有吸引力，因为我以三种方式尝试过，但最终都失败了：

  1. 在以前的公司，我们在数据库中有配置设置，但当然你不能把它们都放在那里，因为你需要配置到那个数据库的连接字符串。此外，在部署之前确保数据库得到正确更新同样困难。
  2. 我们尝试过的另一种方法是建立一个网络服务，作为一种集中式注册中心。这几乎奏效了，但是本地缓存总是存在问题，确保配置服务器的 URL 正确配置，当然还有配置配置服务器。
  3. 活动目录？哇！需要我多说？

想法？

您在使用我正在考虑的选项方面取得了多大的成功？是否有其他对您有效的替代方案？

4

5 回答 5

3

我想说做几件事：

首先，使用登台服务器。无论是工程还是非工程，都有一个位置可以将代码“模拟部署”到服务器，并从那里进行测试。这提供了一个很好的目的，即提供一个独特的“类似生产”的环境来进行测试，并且它允许进行部署培训，而不会导致每个人都因为害怕在部署中破坏所有内容而变得异常和颤抖。它在硬件方面的成本要高一些，但从它所防止的错误中可能是值得的。

其次，如果您的配置文件确实很复杂，并且非工程师很难构建它们，请创建一个快速工具来创建您的验证文件以进行部署。一个简单的网站，甚至是客户端应用程序，只需要基本的部署参数，对它们进行一些验证，然后以正确的格式保存所有内容，在帮助一些技术含量较低的人方面可以创造奇迹。相信拥有一个验证您的输入的工具对于这些类型的人来说真的很有用，并且知道您总是会拥有经过验证的结果的格式良好的 XML，这也可以节省一些工程师的担心时间。

于 2009-06-15T19:28:31.583 回答
2

我们有一个在我们使用的构建之后运行的自定义 exe。

我们的项目有 4 个配置文件

web.config -- 开发（本地机器）
web.integration.config -- alpha 测试（在我们的 alpha 服务器上运行）
web.staging.config -- beta 测试（在我们的 beta 服务器上运行）
web.production.config -- 生产（在我们的生产服务器上运行）

exe只是删除所有文件，除了需要的文件，然后将其重命名为web.config ...

我们不允许非开发人员（QA、DBA 等）操作配置文件，因为它们可能会更改为生产值（邮件服务器、sql 服务器）并导致一些严重问题......

它对我们非常有效

于 2009-06-15T19:34:34.847 回答
1

我见过一些公司使用部署脚本和镜像生产的虚拟机来进行 QA 构建和暂存构建，只需按一下按钮就可以部署到他们身上。您可以使用 Powershell 来执行此操作。

于 2009-06-15T19:24:11.467 回答
0

以前的公司我们实施了这个：

  • 开发人员为每个应用程序创建主配置文件
  • 识别特定于机器/环境的令牌并将其移至单独的文件
  • CI 机器进行检查，用新版本号标记文件，运行测试，然后将应用程序复制到变更管理人员控制的中央共享。
  • 变更管理拉起我们漂亮的部署仪表板。然后他们选择他们想要的应用程序、请求的版本和请求的环境。然后他们按下了开始按钮。
  • 部署应用程序将所有文件从暂存文件共享中自动复制到服务器。
  • 部署应用程序然后启动构建脚本中的任何进一步任务。
  • NAnt 脚本被复制到每台目标机器，然后使用 P/Invoke 启动

一切都是使用 Anthill、NAnt、Robocopy 和一个协调部署的轻量级自定义应用程序实现的。使用

最大的好处是我们几乎没有手动部署步骤。从开发部署开始，一切都是可重复和可测试的。

为此，我们尽可能地进行了隔离。我们在很大程度上避免了 GAC 和 machine.configs。随着时间的推移，我们发现这对提高速度有很大帮助，因为无论如何，所有应用程序都不一定要迁移到共享组件的新版本。

于 2009-06-15T19:43:31.567 回答
0

我一直在混合本地和数据库驱动的设置存储方面取得成功。特定于机器的设置存储在机器上的一个 XML 文件中（这包括我们的根数据库的连接信息），任何特定于应用程序（但不是特定于用户）的设置也是如此。任何用户特定或企业范围的设置都存储在数据库中，包括其他数据库的连接信息。换句话说，我们有一个包含此信息的数据库，然后客户端可以使用该数据库连接到其他数据库。这使我们能够集中维护除与根数据库的连接之外的所有内容。

于 2009-06-15T19:30:23.623 回答