持续集成和 Web 部署工作流程

Question

我们正在寻求改进 SDLC 的几个方面。我们现在拥有的是以下内容，与几年前相比，这些都是相当新的光年：

• 代码：我们主要是一家 .Net 商店。我们主要开发 Web 应用程序（MVC/SQL Server）。但我们也有一些批处理控制台应用程序。
• SCM：Git 和企业 GitHub。大多数工作直接在主分支（队列 boo-hiss）中完成，但我们认识到需要转向分支模型。我们将实现Vincent Driessen's model 的一些风格。
• CI 服务器：Team City。一两年前，我们迫切需要设置部署自动化以避免充满危险的手动脚本。我们现在使用 TeamCity 通过 PowerShell 启动部署脚本。 （它使用 msbuild 来简单地构建目标配置——标准是 Debug 和 Release；我们在每个解决方案中设置了 Dev、QA 和 Prod 配置——在 Visual Studio 解决方案中定义。）遗憾的是，我们还没有实际使用TeamCity 的预期目的是持续集成。为此，我们需要实现 TDD。部署自动化从每个存储库的主分支中提取。
• 环境：我们有 3 个环境，每个环境都有专用的 Web、批处理和数据库服务器。我们称他们为 Dev、QA 和 Prod。 Dev 是我们的测试环境。 QA 是供最终用户测试的。产品是产品。通常，我们的部署自动化会将每个应用程序推送到每个环境一次。它目前无法处理将同一应用推送到单个环境中的多个位置。

请注意，我们开始遇到需要进行并行开发的情况：一个功能正在一个分支中开发；另一个在另一个分支；和另一个修补程序。显然，在 master 中做所有事情是不可接受的。

这是我想去的地方：

• 在 Git 中开始一个分支模型。
• 将部署自动化从 Team City 移到自定义、强大的部署工具中。
• 实施 TDD。
• 将 TeamCity 用于其预期目的，即持续集成。

这些是高级目标，我对如何开始执行此操作（尤其是部署自动化）有粗略的想法。然而，我有一些相当大的悬而未决的问题让我的（哇哈哈）总体规划感到沮丧。以下是我希望 SO 社区提供的以下内容：

1. 当您执行 CI 并启动自动化测试时，您针对哪些分支执行此操作？我认为，理论上，您不希望“开发”和（显然）“主”分支中的“损坏”代码。您是否针对“开发”或所有分支使用 CI？
2. 在将代码移至 prod 之前或之后，您是否合并到 master 中？换句话说，你是从开发者还是从大师那里推到产品的？
3. 有时我们需要测试（至少在 QA 中，可能在 Dev 中）并行更改，例如错误修复和功能。您是否确实设置了多个测试网站（例如 myappqa1.blah.com 和 myappqa2.blah.com 等）？这些多种环境如何影响您的部署自动化？
4. 出于好奇，您是否进行夜间构建——如果是，针对哪个分支？您会在任何地方部署此夜间构建吗？
5. 您如何打包您的应用程序（即商店版本）？现在，我们使用 TeamCity 和 PowerShell 针对 VS 中定义的配置运行 msbuild。它将所有环境构建放入一个 zip 文件中。这存储为 TeamCity 构建的工件。这是我在谈论的内容的视觉效果： 然后另一个脚本将从 zip 文件中选择正确的环境并进行部署。我们应该以某种方式将发布包存储在 Team City 或 Git（使用“发布”功能）中吗？
6. 与您的部署自动化相关：您是部署以前打包/构建的应用，还是一举构建和部署所有应用？

非常感谢您的反馈！

谢谢 汤姆

Answer 1

作为BuildMaster（TeamCity 结束后立即使用的工具，可能是您正在寻找的工具）的开发人员，我可以尝试回答其中的大部分问题。

当您进行 CI 并启动自动化测试时，您会做什么分支 这反对？我在想，理论上，你不想“破碎” 您的“开发”和（显然）“主”分支中的代码。你踢吗 CI 反对“开发”或所有分支？

我们遵循“branch-by-rule”和“branch-by-exception”模型，其中开发要么针对“发布”分支完成，要么针对主干/主干完成。功能分支也可以存在于本地开发中，但它们本身并不是构建和发布到集成和超越的（即它们与“发布”分支合并，无论它是在主干/主干还是单独的）。

您可以在Source Control Done Right 中阅读有关此过程的更多信息。

您是在将代码移至 prod 之前还是之后合并到 master 中？ 换句话说，你是从开发者还是从大师那里推到产品的？

强烈建议您不要为个别环境保留单独的分支。我知道这正在成为最近所有分布式源代码控制系统的一种趋势，但根据我们的经验，如果不遵守特殊纪律，它会导致许多问题。主要问题是：缺少/忘记合并、从一个环境到下一个环境的不兼容合并、未经测试的代码意外合并到新环境等等。

所以要回答这个问题，分支代码（用于“按规则分支”）或主干/主代码（用于“按异常分支”）是在发布后推送到生产中的内容以前的测试环境。

有时我们需要并行测试（至少在 QA 中，也许在 Dev 中） 更改，例如错误修复和功能。你真的设置了多个 测试网站（例如 myappqa1.blah.com 和 myappqa2.blah.com 等）？ 这些多种环境如何影响您的部署 自动化？

这种类型的测试本质上是一种预集成测试，因为测试人员正在测试功能，而不会将它们与其他开发集成。完全集成的代码是需要测试的。您可以拥有任意数量的预集成环境，就像您可以拥有任意数量的本地开发环境一样。

出于好奇，您是否会在夜间进行构建——如果是，反对 什么分支？你会在任何地方部署这个夜间构建吗？

是的，但它们对我们的团队来说基本上没有用，因为一旦您自动化了构建和发布过程，创建新的构建是微不足道的，因为它们是必要的。对于较大的团队或面向公众的下载，它当然会有所帮助。该构建被恰当地部署到“集成”环境中。使用的分支由为其创建构建的版本决定。

您如何打包您的应用（即商店版本）？ ... 我们应该吗 将发布包存储在 Team City 或 Git 中（使用“发布” 功能）以某种方式？

每个环境单独构建是一种反模式。对于您部署到的每个环境，部署单元应该相同，当然例外是：

• 应用程序配置 - 例如用于 .NET、web.config/App.config 文件
• 基础架构部署 - 例如设置 IIS/网站（这与应用程序部署正交，通常由 Ops 团队处理，因此需要 DevOps，但这是一个完全不同的主题）
• 数据库更改 - 这些更改本身就很特殊，因为一旦您DROP 列，就不能再次删除它。你可以阅读更多关于这些的内容：Database Changes Done Right

与您的部署自动化相关：您之前是否部署过 打包/构建的应用程序，还是一举构建和部署？

常见的方法是将构建和部署分开。对于简单的网站（即宣传册网站），无需进行这种区分，“持续生产”就足够了。

当其他部分和部分需要组合在一起时，这当然会变得模糊不清。例如，发布我们的 BuildMaster 软件需要一个安装程序供公众使用。安装程序直到后来的环境才被使用，对早期环境的部署是通过预打包的构建工件（安装程序也使用它）完成的。这是从一开始就保留一个部署单元（即工件集）的地方，可以轻松地部署到任何有或没有安装程序的环境。

TL,DR - 总结这么广泛的主题真的很难...但是如果您想在不进行大量前期投资的情况下开始使用，我建议您查看由同事撰写的这个新的Incremental Continuous Delivery paper .