首页 文章

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

提问于
浏览 次
3

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

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

CURRENT PROCESS OF RELEASE

  • 在QA和INTEGRATION分支之间区分SCM的最新版本 .

  • 在这些分支之间手动复制/粘贴 "relevant" 更改 .

  • 将最新的二进制文件复制到正确的位置（这是使用.cmd脚本自动完成的） .

  • 重启任何服务

MY QUESTION

我希望完全避免步骤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环境位于不同的数据中心，并且几乎没有同步（随着开发变得更快/更好/更强，它们会逐渐分开） . 在"release"期间（例如，这些是从QA合并到INTEGRATION的 not "relevant" changes ），URL / endpoints 不同的更改将被忽略 .

即使在常规版本中（大约每周一次），我也必须处理十几个配置文件更改，这些更改必须从QA发布到集成，我必须手动浏览每个配置文件并复制/粘贴非URL相关的更改文件 . 我不能简单地使用CI工具从QA（或QA之后）吐出的整个包，因为URL / endpoints 是不同的 .

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

SUMMARY OF ENVIRONMENTS/PROGRAMMING LANGUAGES/OS/ETC.

  • 多种编程语言 - C＃，C，Java，Ruby . 管理层意识到这是一个问题，因为发布团队必须成为所有行业的王者并正在解决这个问题 .

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

  • SCM - Perforce，TFS . 管理层正试图将每个人都转移到一个工具（可能是TFS）

  • CI正在被提倡，虽然不是强制性的 - 管理层正在推动变革，但需要时间 .

  • 我举了QA和INTEGRATION的例子，但实际上有QA（由开发人员测试人员管理），INTEGRATION（由我的团队管理），STABLE（由我的团队发布到STABLE但由 生产环境 行动支持），PRODUCTION（支持者 生产环境 行动） . 这些是官方环境 - 其他人目前都是非正式的，但开发人员或测试团队还有一些 . 我最终也想开始标准化/巩固这些非正式的环境，因为开发者测试不应该担心做这种事情 .

  • 使用DeployIT（http://www.xebialabs.com/products）等工具标准化二进制文件的部署工作有很多工作要做，这可能会提供一些简化这些配置更改的方法 .

  • 开发团队敏捷并且经常发布，但这只意味着更多的工作差异配置文件 .

SOLUTIONS SUGGESTED BY TEAM MEMBERS:

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

  • 或者，一些团队成员正在使用安装脚本（InstallShield / MSI）来自动执行env之间的查找/替换或URL / enpoints . 我希望这不是解决方案，但它是可行的 .

如果我遗漏了任何内容或应该提供更多信息，请告诉我 .

谢谢

[更新]参考文献：

deployment language-agnostic release-management

4 回答

  • 0

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

    首先，阅读本书，我回答了有关软件交付的每一个问题，以及许多我从未想过要问的问题：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 .

    使用Continuous Integration服务器，我们使用TeamCity，到目前为止对它非常满意 .

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

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

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

    对我们来说，Powershell，XML和Web Deploy参数化将起到重要作用 .

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

    祝好运！

    回复于
  • 0

    通常问题并不太难 - 您需要为每个环境分支分支并为它们 Build CI构建设置 . 因此，与QA分支的合并将触发该代码的构建和QA的自定义部署 . 简单 .

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

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

    我不会尝试管理一些在源代码管理中获取单个配置文件并在构建或预部署步骤中使用不同数据重写它的自动方式 . 这种方式就是疯狂，以及为维护数据和工具而进行的大量持续麻烦 . 保持单独的配置，并确保开发人员知道在他们进行更改时更新所有配置 . （或者，你可以在SCM树中保存1个配置，并确保他们知道合并他们的更改不得覆盖任何现有的修改 - 多个配置更容易）

    回复于
  • 0

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

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

    回复于
  • 0

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

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

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

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

    • 保持配置文件的结构一致/标准化，例如XML . 尝试将特定于环境的 endpoints 保留在此配置文件中，但以允许轻松访问特定单个节点/设置（例如，使用XPath）的方式存储它们 .

    • 在部署到特定环境时，您的部署工具应该能够解析（例如，使用XPath）并将特定于环境的 endpoints 更新为您要部署的特定环境的值 .

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

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

    回复于

相关问题