3

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

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

目前的发布过程

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

我的问题

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

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

即使在常规版本中（大约每周一次），我也必须处理必须从 QA 发布到集成的十几个配置文件更改，并且我必须手动检查每个配置文件并在文件。我不能简单地获取 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 和 INTEGRATION 的示例，但实际上有 QA（由开发人员 + 测试人员管理）、INTEGRATION（由我的团队管理）、STABLE（由我的团队发布到 STABLE 但由 Production Ops 支持）、PRODUCTION（由生产操作）。这些是官方环境 - 其他目前是非官方的，但开发人员或测试团队还有一些。我最终也想开始标准化/整合这些非官方的环境，因为开发人员+测试不应该担心做这种事情。
  6. 使用 DeployIT ( http://www.xebialabs.com/products ) 等工具来标准化二进制文件的部署方式有很多工作要做，这可能会提供一些方法来简化这些配置更改。
  7. 开发团队很敏捷并且经常发布，但这仅仅意味着更多的工作来区分配置文件。

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

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

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

谢谢

[更新] 参考资料：

  1. 在部署环境之间管理复杂的 Web.Config 文件- 特定于 C# web.config，虽然是一个很好的开始。
  2. http://www.hanselman.com/blog/ManagingMultipleConfigurationFileEnvironmentsWithPreBuildEvents.aspx - 好的，虽然乍一看，这似乎相当初级，可能很容易破坏。
4

4 回答 4

0

Generally the problem isn't too difficult - you need branches for each of the environments and CI build setup for them. So a merge to the QA branch would trigger a build of that code and a custom deployment to QA. Simple.

Now managing multiple config files isn;t quite so easy (unless you have 1 for each environment, in which case you just call them Int.config, QA.config etc, store them all in the SCM, and pick the appropriate one to use in each branch's deployment script - eg, when the build for QA runs, it picks qa.config and copies it to the correct location and renames it to the correct name)(incidentally, this is the approach I tend to use as its very simple).

If you have multiple configs you need to use, then its always going to be a manual process - but you can help yourself by copying all the relevant configs to a build staging area that an admin will use to perform the deployment. Its a good first step in that the build they have in a staging directory will be the correct one for them, they just have to choose which config to use either during (eg as an option in the installer) or by manually copying the appropriate config over.

I would not try to manage some automated way of taking a single config file in source control and re-writing it with different data in the build, or pre-deploy steps. That way lies madness, and a lot of continual hassle trying to maintain the data and the tooling. Keep separate configs in place and make sure the devs know to update all of them when they make a change. (Or, you can hold 1 config in the SCM tree and make sure they know that merging their changes must not overwrite any existing modifications - multiple configs is easier)

于 2013-04-26T23:23:15.520 回答
0

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

首先，阅读这本书，我已经完成了 2/3，它回答了我关于软件交付的所有问题，以及许多我从未想过要问的问题：http: //www.amazon.com/Continuous-Delivery -部署-自动化-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 参数化将发挥重要作用。

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

祝你好运！

于 2013-06-13T05:53:50.813 回答
0

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

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

于 2013-04-30T23:48:36.600 回答
0

感谢@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-网络部署/网络部署参数化(WebDeploy)
  2. http://docs.xebialabs.com/releases/3.9/deployit/packagingmanual.html#using-placeholders-in-ci-properties (DeployIt)
  3. 使用 XPath 查找和替换的自制解决方案。

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

于 2013-05-19T21:58:07.450 回答