deployment - 向不同环境发布管理(开发/质量保证/集成/稳定)

Question

我最近加入了一家公司，担任发布工程师，在这里，大量的开发团队以各种语言开发了众多服务，应用程序和Web应用程序，它们之间具有各种相互依赖性。

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

当前发布过程

将QA和INTEGRATION分支之间的SCM最新修订版进行比较。

在这些分支之间手动复制/粘贴“相关” 更改。

将最新的二进制文件复制到正确的位置(这使用.cmd脚本自动执行)。

重新启动任何服务

我的问题

我希望完全避免步骤1.和2.，但是却遇到了这样的问题:环境之间的差异导致配置文件针对不同的环境而有所不同(例如QA与INTEGRATION)。这是一个示例:

在质量检查环境中:

<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 /端点不同的更改在“发布”期间将被忽略(即 与“relevant”无关)将从QA合并到INTEGRATION。

即使是常规发行版(大约每周一次)，我也必须处理从质量检查到集成的大量配置文件更改，而且我必须手动浏览每个配置文件，然后在/之间复制/粘贴非URL相关的更改。文件。我不能简单地将CI工具从质量检查中(或在质量检查后)吐出来的整个程序包拿出来，因为URL /端点是不同的。

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

环境/编程语言/ OS / ETC的摘要。

多种编程语言-C#，C++，Java，Ruby。管理层意识到这是问题之一，因为发布团队必须是万事通，并且正在解决这个问题。

多个操作系统-Windows 2003/2008/2012，CentOS，Red Hat，HP-UX。管理层也正在解决此问题-开始整合并限制于Windows 2012和CentOS。

SCM-Perforce，TFS。管理层正在尝试将所有人转移到单个工具(可能是TFS)

有人倡导

CI，尽管不是强制性的-管理层正在推动变革，但需要时间。

我已经给出了质量检查和集成的示例，但实际上有质量检查(由开发人员和测试人员管理)，集成(由我的团队管理)，稳定(由我的团队发布到STABLE但受生产运营支持)，生产(受支持)由生产运营)。这些是官方环境-其他目前不是官方环境，但开发人员或测试团队还有更多。我最终还是想开始标准化/整合这些非官方的环境，因为开发人员+测试人员不必担心这样做。

目前正在进行大量工作来标准化使用DeployIT(http://www.xebialabs.com/products)之类的工具来部署二进制文件的方式，这些工具可能会提供一些简化这些配置更改的方法。

开发人员团队通常敏捷并且经常发布，但这仅意味着在配置文件上进行更多工作。

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

当前的思路是使用LoadBalancer并在不同环境中标准化名称，但是我不确定像这样的“进程”是否是正确的解决方案。必须有一种更好的方法，可以从开发人员如何编写配置到发布环境如何满足依赖关系开始。

另外，一些团队成员正在研究安装脚本(InstallShield / MSI)，以自动在环境之间查找/替换或URL /指定。我希望这不是解决方案，但可行。

如果我错过了任何事情或应该提供更多信息，请告诉我。

谢谢

[更新]
参考文献:

Managing complex Web.Config files between deployment environments-特定于C#web.config，尽管这是一个很好的开始。

http://www.hanselman.com/blog/ManagingMultipleConfigurationFileEnvironmentsWithPreBuildEvents.aspx-好的，尽管乍一看，这似乎很初级，很容易打破。

Answer 1

通常，问题并不是很难-您需要为每个环境设置分支，并为它们创建CI构建。因此，合并到QA分支将触发该代码的构建以及对QA的自定义部署。简单。

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

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

我不会尝试以某种自动化的方式来管理源代码管理中的单个配置文件，并在构建或预部署步骤中用不同的数据重新写入它。那就是疯狂，还有很多持续的麻烦试图维护数据和工具。保留单独的配置，并确保开发人员在进行更改时知道更新所有配置。 (或者，您可以在SCM树中保留1个配置，并确保他们知道合并其更改一定不能覆盖任何现有修改-多个配置更容易)