如何实现 .NET 部署必杀技？
我们公司即将“上线”日期（以及获得 QA 部门的日期），我正在尝试定义正确的操作流程来支持这一点。 我的一个重要考虑是如何避免不可避免地发生的部署/配置地狱。 你们中是否有人找到了将构建移交给非程序员的良好解决方案，以便他们可以在 QA、暂存和生产环境中成功安装和配置它？
对我们来说，一个完整的环境由异构计划任务、Windows 服务和网站的混合组成，所有这些都可以通过并行部署进行扩展。 值得庆幸的是，配置方式是一致的。 不幸的是，这一切都是通过 .NET web/app.config 文件进行管理的。 根据我的经验，QA 和运维人员在尝试修改它们时总是会搞砸（XML 对于大多数人来说出人意料地难以处理！）
以下是我正在考虑的选项：
使用 machine.config 文件
这是我在实践，但看起来很有希望。 如果我们创建一个 machine.config 模板，其中包含每个应用程序的每个设置（可能因环境而异），这将允许管理员对一个文件进行所有更改并将其部署到环境中的每台计算机。
- Pros:
- 这可能会减少部署系统所需的步骤数
- Cons:
- 必须以某种方式记录配置架构更改
- Unknowns:
- 我们使用自定义配置节和引用程序集的其他配置扩展。 这是否需要我们在机器的 GAC 中安装 .NET 程序集？
在构建过程中执行配置文件操作
如果我们设置了 QA、暂存和生产环境，使它们看起来与我们的软件（虚拟服务器和 LAN 等）相同，那么 QA 应该能够将准备好的软件直接转换为无需配置更改的软件暂存环境以及暂存到生产。 通过这种设置，理论上我们可以将 QA 预配置的 foo.config 文件交给没有人需要接触的文件。
- Pros:
- 工程人员将更擅长确保配置文件有效
- Cons:
- 对于工程人员来说，了解生产配置可能被认为是糟糕的安全实践（恕我直言，这是一个糟糕的论点）
拥有一个网络集中的设置存储库
这对我来说看起来没有吸引力，因为我尝试了三种方法，但最终都失败了：
- 在以前的公司，我们在数据库中有配置设置，但当然你不能把它们全部放在那里，因为你需要配置连接字符串到该数据库。 此外，确保数据库在部署之前得到正确更新也同样困难。
- 我们尝试过的另一种方法是拥有一个充当集中式注册表的网络服务。 这几乎可行，但本地缓存总是存在问题，确保配置服务器的 URL 正确配置，当然还有配置配置服务器。
- 活动目录？ 呃！ 需要我多说？
想法？
您使用我正在考虑的选项的效果如何？ 除了这些之外，还有其他对您有效的替代方案吗？
Our company is nearing its "go live" date (and its getting a QA department date), and I'm trying to define the right operational processes to support this. A big consideration of mine is how to avoid the deployment/configuration hell that has inevitably occurred. Have any of you found a good solution for handing off builds to the non-programmers so that they could successfully install and configure it in a QA, staging, and production environment?
A full environment for us is composed of a mixture of heterogeneous scheduled tasks, Windows services, and web sites, all of which can be scaled out through parallel deployment. Thankfully, the means of configuration is consistent. Unfortunately, it's all managed through .NET web/app.config files. In my experience, QA and ops folks always mess up when trying to modify them (XML is surprisingly hard for most people to handle!)
Here's the options I'm considering:
Using machine.config files
This is something I haven't done in practice, but it looks promising. If we create a machine.config template containing every setting for every application that can vary by environment, this would allow an admin to make all changes to one file and deploy it to each machine in the environment.
- Pros:
- This potentially reduces the number of steps necessary to deploy a system
- Cons:
- Having to somehow document configuration schema changes
- Unknowns:
- We make use of custom config sections and other configuration extensions that reference assemblies. Would this require us to install our .NET assemblies in the machines' GACs?
Perform config file manipulations in build process
If we set up the QA, staging, and production environments so they appear identical to our software (virtual servers and LANs, etc), QA should be able to transition ready software with no configuration changes directly to the staging environment, and staging to production. With this setup, theoretically we could hand to QA pre-configured foo.config files that nobody needs to touch.
- Pros:
- Engineering would be more adept at ensuring that configuration files are valid
- Cons:
- It may be considered poor security practice for engineering to be aware of production configurations (a poor argument, IMHO)
Have a network-centralized settings repository
This one doesn't look attractive to me, because I tried this in three ways that were ultimately failures:
- At a prior company, we had the configuration settings in the database, but of course you can't put them all in there, since you need to configure the connection string to that database. Also, it was just as difficult to ensure that the database got properly updated before deployment.
- Another approach we'd tried was to have a networked service that worked as sort of a centralized registry. This almost worked, but there were always issues with local caching, ensuring that the URL to the config server was properly configured, and of course configuring the config server.
- Active Directory? Ew! Need I say more?
Thoughts?
How successful have you been with using the options I'm considering? Are there any alternatives to these that have worked well for you?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我想说做几件事：
首先，使用临时服务器。 无论是工程还是非工程，都有一个位置可以将代码“模拟部署”到服务器，并从那里进行测试。 这样做的一个很好的目的是提供一个独特的“类似于生产”的环境来进行测试，并且它允许进行部署培训，而不会导致每个人都因担心破坏部署中的所有内容而变得怪异和摇摇欲坠。 就硬件而言，它的成本要高一些，但从它可以防止的错误来看，这可能是值得的。
其次，如果您的配置文件确实很复杂，并且非工程师很难构建它们，请创建一个快速工具来创建用于部署的验证文件。 一个简单的网站甚至客户端应用程序只需获取基本的部署参数，对它们进行一些验证，然后以正确的格式保存所有内容，就可以在帮助一些技术含量较低的人员方面创造奇迹。 对于这些类型的人来说，拥有一个可以验证输入的工具确实很有用，并且知道您总是会拥有带有经过验证的结果的格式良好的 XML，这也可以节省一些工程师的担忧时间。
I'd say do a couple of things:
First, use a staging server. Whether for engineering or non-engineering, have a location where you perform "mock deployments" of your code to the server, and where it's tested from there. This serves a good purpose of giving a distinct "production-like" environment to test from, and it allows for deployment training without causing everybody to go all freaky and shaky from fear of nuking everything on a deployment. It costs a bit more in terms of hardware, but it's probably worth it from the errors that it prevents.
Second, if your configuration files are truly complex and they're hard for non-engineers to construct, create a quick tool that will create your validation files for deployment. A simple website or even client-side app that just takes the basic deployment parameters, does some validation on them, and then saves everything in the right format can do wonders in terms of helping out some of the less-technical folks. The confidence that having a tool that validates your input can be really useful for those types of folks, and knowing that you're always going to have well-formed XML with validated results can save some engineer worry time as well.
我们有一个自定义的 exe，它在我们使用的构建之后运行。
我们的项目有 4 个配置文件
web.config --development (local box)
web.integration.config -- alpha 测试（在我们的 alpha 服务器上运行）
web.staging.config -- beta 测试（在我们的 beta 服务器上运行）
web.product.config -- 生产（在我们的生产服务器上运行）
exe 只是删除除所需文件之外的所有文件，然后将其重命名为 web.config...
我们不允许非开发人员（ QA、DBA 等）来操作配置文件，因为它们可能会更改为生产值（邮件服务器、sql 服务器）并导致一些严重的问题...
这对我们来说非常有效
We have an custom exe that runs after builds that we use.
Our projects have 4 config files
web.config -- development (local box)
web.integration.config -- alpha testing (runs on our alpha server)
web.staging.config -- beta testing (runs on our beta server)
web.production.config -- production (runs on our production server)
the exe simply deletes the all files except for the one needed and then renames it to web.config...
We don't allow non-developers (QA, DBA, etc) to manipulate the config files as they could change to production values (mail server, sql server) and cause some serious issues...
It works very well for us
我见过一些公司使用部署脚本和镜像生产的虚拟机来进行 QA 构建和暂存构建，只需按一下按钮即可部署到它们。 您可以使用 Powershell 来执行此操作。
I've seen companies use a deployment script and Virtual Machines that mirror production to have QA Builds and staging builds that are deployed to them at the press of a button. You can use Powershell to do this.
我一直成功地混合使用本地和数据库驱动的设置存储。 特定于计算机的设置存储在计算机上的 XML 文件中（这包括根数据库的连接信息），任何特定于应用程序（但不是特定于用户）的设置也是如此。 任何用户特定或企业范围的设置都存储在数据库中，包括其他数据库的连接信息。 换句话说，我们有一个包含此信息的数据库，然后客户端可以使用该数据库连接到其他数据库。 这使我们能够集中维护除根数据库连接之外的所有内容。
I've always had success with a mix of local- and database-driven settings storage. Machine-specific settings were stored in an XML file on the machine (this included connection information for our root database), as were any application-specific (but not user-specific) settings. Anything user specific or enterprise-wide settings were stored in the database, including connection information for OTHER databases. In other words, we had a single database with this information in it, which the client could then use to connect to other databases. This allowed us to centrally maintain everything except the connection to our root database.
我们以前的公司实现了这一点：
一切都是使用 Anthill、NAnt、Robocopy 和一个协调部署的轻量级自定义应用程序实现的。 使用
最大的好处是我们几乎从未有过手动部署步骤。 从开发部署开始，一切都是可重复和可测试的。
为此，我们尝试尽可能地隔离。 我们很大程度上避免了 GAC 和 machine.configs。 随着时间的推移，我们发现这对速度有很大帮助，因为所有应用程序不一定都想迁移到共享组件的新版本。
Previous company we implemented this:
Everything was implemented using Anthill, NAnt, Robocopy, and a lightweight custom app that orchestrated the deployments. Using
The biggest upside to this is that we almost never had a manual deployment step. Everything was repeatable and testable from dev deployments onward.
To this end, we tried to isolate as much as possible. We largely avoided the GAC and the machine.configs. We found over time that this helped with velocity quite a bit since all apps didn't necessarily want to move to new versions of shared components anyway.