发布管理到不同的环境（Dev/QA/Integration/Stable）

Question

我最近加入了一家公司，担任发布工程师，该公司的大量开发团队以各种语言开发大量服务、应用程序、网络应用程序，它们之间存在各种相互依赖关系。

我正在尝试找到一种方法来简化并最好自动化发布。目前，发布团队正在执行以下操作来“发布”软件：

目前的发布过程

1. 在 QA 和 INTEGRATION 分支之间区分来自 SCM 的最新版本。
2. 在这些分支之间手动复制/粘贴“相关”更改。
3. 将最新的二进制文件复制到正确的位置（这是使用 .cmd 脚本自动完成的）。
4. 重启所有服务

我的问题

我希望完全避免步骤 1. 和 2.（显然），但我遇到了环境之间的差异导致配置文件因不同环境而异（例如 QA 与 INTEGRATION）的问题。这是一个示例：

在 QA 环境中：

<setting name="ServiceUri" serializeAs="String">
        <value>https://servicepoint.QA.domain.net/</value>
</setting>

在集成环境中：

<setting name="ServiceUri" serializeAs="String">
        <value>https://servicepoint.integration.domain.net/</value>
</setting>

如果您仔细观察，上面两个<setting> 标记之间的唯一区别就是<value> 标记中的URL。这是因为 QA 和 INTEGRATION 环境位于不同的数据中心，并且稍微不同步（随着开发变得更快/更好/更强，它们会逐渐分开）。此类 URL/端点不同的更改在“发布”期间将被忽略（即这些不是“相关”更改以从 QA 合并到 INTEGRATION）。

即使在常规版本中（大约每周一次），我也必须处理必须从 QA 发布到集成的十几个配置文件更改，并且我必须手动检查每个配置文件并复制/粘贴非 URL 相关文件之间的变化。我不能简单地拿 CI 工具从 QA（或 QA 之后）吐出的整个包，因为 URL/端点不同。

由于使用了多种编程语言，上面的配置文件示例可以是 C#、C++ 或 Java。所以我希望任何解决方案都与语言无关。

环境/编程语言/操作系统/等的总结。

1. 多种编程语言 - C#、C++、Java、Ruby。管理层意识到这是问题之一，因为发布团队必须是万事通并正在解决这个问题。
2. 多操作系统 - Windows 2003/2008/2012、CentOS、Red Hat、HP-UX。管理层也在解决这个问题 - 开始整合并限制在 Windows 2012 和 CentOS。
3. SCM - Perforce，TFS。管理层正试图让每个人都使用单一工具（可能是 TFS）
4. CI 被提倡，但不是强制性的 - 管理层正在推动变革，但需要时间。
5. 我已经给出了 QA 和集成的示例，但实际上有 QA（由开发人员+测试人员管理）、INTEGRATION（由我的团队管理）、STABLE（由我的团队发布到 STABLE 但由 Production Ops 支持）、PRODUCTION （由生产运营支持）。这些是官方环境 - 其他目前是非官方的，但开发人员或测试团队还有一些。我最终也想开始标准化/整合这些非官方环境，因为开发人员+测试不必担心做这类事情。
6. 使用 DeployIT (http://www.xebialabs.com/products) 等工具来标准化二进制文件的部署方式需要做大量工作，这可能会提供一些方法来简化这些配置更改。
7. 开发团队很灵活并且经常发布，但这只是意味着需要更多的工作来区分配置文件。

团队成员建议的解决方案：

1. 目前的想法是使用 LoadBalancer 并在不同环境中标准化名称，但我不确定像这样的“流程”是否是正确的解决方案。一定有更好的方法可以从开发人员如何编写配置到发布环境如何满足依赖关系开始。
2. 另外，一些团队成员正在开发安装脚本 (InstallShield / MSI)，以在 env 之间自动查找/替换或 URL/enpoints。我希望这不是解决方案，但它是可行的。

如果我遗漏了什么或应该提供更多信息，请告诉我。

谢谢

[更新] 参考资料：

1. Managing complex Web.Config files between deployment environments - 特定于 C# web.config，虽然是一个很好的开始。
2. http://www.hanselman.com/blog/ManagingMultipleConfigurationFileEnvironmentsWithPreBuildEvents.aspx - 好的，虽然乍一看，这似乎相当简陋，很容易坏。

Answer 1

一般来说，这个问题并不太难——您需要为每个环境设置分支并为它们设置 CI 构建。因此，与 QA 分支的合并将触发该代码的构建和对 QA 的自定义部署。简单的。

现在管理多个配置文件并不那么容易（除非每个环境都有 1 个，在这种情况下，您只需将它们称为 Int.config、QA.config 等，将它们全部存储在 SCM 中，然后选择合适的在每个分支的部署脚本中使用一个 - 例如，当 QA 构建运行时，它会选择 qa.config 并将其复制到正确的位置并将其重命名为正确的名称）（顺便说一下，这是我倾向于使用的方法它非常简单）。

如果您需要使用多个配置，那么它始终是一个手动过程 - 但您可以通过将所有相关配置复制到管理员将用于执行部署的构建暂存区域来帮助自己。这是一个很好的第一步，因为他们在暂存目录中的构建对他们来说是正确的，他们只需要选择在期间使用哪个配置（例如作为安装程序中的一个选项）或通过手动复制适当的配置结束了。

我不会尝试管理在源代码管理中获取单个配置文件并在构建或预部署步骤中使用不同数据重写它的自动化方式。这种方式很疯狂，并且在尝试维护数据和工具时会遇到很多麻烦。保留单独的配置，并确保开发人员知道在进行更改时更新所有配置。 （或者，您可以在 SCM 树中保留 1 个配置，并确保他们知道合并他们的更改不能覆盖任何现有的修改 - 多个配置更容易）

Answer 2

我同意@gbjbaanb。每个环境都有一个配置。让您的开发人员编写从配置文件中读取其属性（包括其 URL）的应用程序，并为每个环境提交配置文件。这不仅可以帮助您进行部署，而且版本控制下的配置文件提供了可重复性、完全透明性以及您环境特定设置的审计跟踪。

就个人而言，我更喜欢通过包含所有环境配置（甚至是您未使用的配置）来创建一个可在任何环境中运行的单个可部署包。然后，您可以进行一些部署自动化，以确定应用程序应该使用哪些配置文件并进行适当的设置。

Answer 3

感谢@gman 和@gbjbaanb 的回答（https://stackoverflow.com/a/16310735/143189、https://stackoverflow.com/a/16246598/143189），但我觉得他们并没有帮助我解决我面临的根本问题，并重申只是为了澄清。

• 代码似乎非常了解它们运行的​​环境。如何编写与环境无关的代码？

以上答案中的建议是为每个环境（环境配置）存储 1 个配置文件。这是可能的，但是任何非环境设置的添加/删除/编辑都必须移植到每个环境配置中。

经过一番研究，我想知道以下是否会更好？

• 保持配置文件的结构一致/标准化，例如XML。尝试将特定于环境的端点保留在此配置文件中，但以允许轻松访问特定单个节点/设置的方式存储它们（例如使用 XPath）。
• 部署到特定环境时，您的部署工具应该能够解析（例如使用 XPath）并将环境特定端点更新为您要部署到的特定环境的值。

以上不是一个独特的想法。已经有一些现有的实现可以解决上述解决方案：

1. http://www.iis.net/learn/develop/windows-web-application-gallery/reference-for-the-web-application-package & http://www.iis.net/learn/publish/using-web-deploy/web-deploy-parameterization (WebDeploy)
2. http://docs.xebialabs.com/releases/3.9/deployit/packagingmanual.html#using-placeholders-in-ci-properties (DeployIt)
3. 使用 XPath 查找和替换的自制解决方案。

简而言之，虽然有特定于编程语言的解决方案和与编程语言无关的解决方案，但我想最大的缺点是在开发过程中也需要考虑发布管理，否则会导致部署问题 - 我不知道' 不喜欢那样，因为这听起来像“开发应该知道将设计什么测试”。是否有必要和方法来避免这种情况，这是个大问题。

Answer 4

我目前正在为 Web 应用程序创建“部署管道”，并且正在筛选类似的问题。你的环境听起来比我们的更复杂，但我有一些想法。

首先，请阅读这本书，我已经完成了 2/3，它回答了我关于软件交付的所有问题，以及许多我从未想过要问的问题：http://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912/ref=sr_1_1?s=books&ie=UTF8&qid=1371099379&sr=1-1

版本控制系统是您最好的朋友。构建可部署包所需的一切绝对都应该可以从您的 VCS 中获取。

使用持续集成服务器，我们使用 TeamCity，到目前为止对它非常满意。

CI 服务器构建与最终目标环境完全无关的包。我们仍然有很多“了解”目标环境的代码，这当然意味着如果我们添加一个新环境，我们必须修改所有这些代码以确保它能够应对，然后重新测试它以确保我们在这个过程中没有破坏任何东西。我现在看到这是容易出错且完全可以避免的。

像 Visual Studio 之类的工具支持配置文件转换，我们对其进行了简要了解，但很快意识到它取决于开发人员使用代码准备的特定于环境的配置文件，以便将其添加到包中。相反，将任何特定于特定环境的设置分解为它们自己的配置机制（例如另一个 xml 文件），并让您的部署工具在部署时将其应用于包。将这些文件保存在 VCS 中，但使用单独的存储库，以便对配置的修订不会触发新构建并导致构建号被错误地夸大。

这样，您的环境特定配置文件仅包含在每个环境基础上更改的内容，并且仅当该环境需要与默认设置不同的内容时。与@gbjbaanb 的建议相反，我们计划做任何必要的事情来保持包“纯”和特定于环境的配置分开，即使它需要自定义脚本等。所以我想我们正在走向疯狂的道路。 :-)

对我们来说，Powershell、XML 和 Web Deploy 参数化将发挥重要作用。

我还计划非常积极地重构配置文件，以便相同的信息不会在不同的地方重复多次。

祝你好运！