使用 VSO 进行 DTAP 部署
0/5 (0投票)
本文介绍如何使用 VSO 设置从 DEV 到 TEST 到 ACC 再到 PROD 的部署流程。
引言
我关于此主题的上一篇文章：在 Microsoft Azure 中部署 Web 应用程序。
大多数项目不是在一个环境中创建/编译的。我们通常将开发环境与生产环境分开，以确保我们的开发代码不会干扰我们的生产代码。生产环境是面向客户运行的，因此应该免受开发人员错误的影响。
一种解决方案是保留源代码的不同版本。当然，你的开发机器上始终会有一个版本。在某些项目中，这甚至是唯一存在的版本……你会惊讶地发现，在我工作过的许多大公司中，情况也是如此。有时，代码会被备份到文件服务器（通常是 ZIP 文件，如“MySources.20150315.zip”），这可以提供*一些*版本控制，但它缺乏增量、轻松合并等功能……
一个更好的解决方案是使用源代码控制系统，例如 Git、Subversion 或 Microsoft Team Foundation Server (TFS)。在本文中，我们将使用 TFS online，它目前伪装成Visual Studio Online (VSO)。如果你不知道我在说什么，请参考我关于此主题的上一篇文章：在 Microsoft Azure 中部署 Web 应用程序。本文还解释了如何在 VSO 中设置你的团队项目，我们将在此基础上继续本文的内容。
如果你知道 DTAP 的含义，可以跳过以下章节，直接进入“我们如何……”
DTAP 的含义是什么？
我们希望确保我们的源代码始终安全，能够以受控的方式应用更改，并且我们能够协同工作。这听起来像是 Microsoft TFS 的广告 :-)
出于所有这些目的，我们将使用 VSO，因为
- 它最多支持 5 个用户免费，之后价格仍然非常合理。
- 它托管在云端，这保证了你的源代码得到妥善存储，并为你自动备份。
- 它还可以让你自动构建和测试你的代码，并在需要时自动部署它。
DTAP 代表Development - Test - Acceptance - Production（开发 - 测试 - 验收 - 生产）。它是使你的代码安全地演进到生产代码的方法之一。让我们更详细地了解 DTAP 的含义。
D(evelopment)（开发）
你通常会在开发 PC 上启动项目，在那里你将准备第一个（不完整的）版本。代码签入后，你将继续在本地进行工作和测试，并偶尔签入你的代码。通常，每完成一个功能，你就会想签入你的代码。或者，如果你写了 bug（我们当然永远不会写 bug），你会在修复 bug 后签入代码。
现在我们达到了“在我机器上可以运行”的阶段。
T(est)（测试）
大多数开发人员（包括我）都会避免将此版本存储在源代码管理中，仅仅因为它尚未完成。但这是一个错误的反应：一旦你有了*某样东西*，你就希望代码是安全的。而且，你的团队中很可能还有其他成员想要参与到项目中。这就是我们在 TFS 中创建 TEST 分支的原因。这是我们将存储代码的分支。根据你所在的团队，可能有一些规则，例如
- 代码必须在签入之前能够编译。这是最基本的要求。你不想成为其他团队成员在获取项目的最新更改后会咒骂的对象。
- 测试必须成功运行。在某些环境中，此条件会放宽。在 TFS 上的自动构建过程中，测试将在构建之后运行，并将输出测试结果。但是，你也不想成为那个破坏了构建或使测试失败的人。
当你在团队中工作时，在你做你的部分时，其他人也会更改代码。因此，在签入你的代码之前，最好*首先*获取最新更改并再次构建/测试你的解决方案。这将确保你不会因为代码不兼容而破坏构建。你不想成为那个破坏了构建/测试的人！
记住：如果它不在源代码管理中，它就不存在。
A(cceptance)（验收）
当你（和你的测试人员）对 TEST 环境中的代码满意时，你可以将更改合并到 TFS 中的 ACCEPTANCE (ACC) 分支。你可以让 TFS 构建自动将代码部署到 ACC 服务器，以便用户可以验证你所做的工作。如果需要应用更改，你应该首先在开发 PC (D) 上进行，然后将其移到 TEST 分支，在那里它将被自动构建和测试，当一切顺利时，再将其合并回 ACC 分支。
通常在 ACC 中，你不再测试功能，因为你已经在 TEST 中完成了。你现在想要关注更高的负载，处理大量数据时会发生什么等等。因此，这就是你的性能和负载测试将进行的地方。确保拥有真实数据的一种方法是将 PROD 数据库复制到 ACC 环境并进行测试。如果你不存储敏感数据，这就可以了。否则，你可能会遇到一些隐私问题。
P(roduction)（生产）
当你的用户满意时（因此验收测试通过），你将执行从 ACC 到 PROD 的相同操作。从那时起，你将在 PROD 分支中拥有（更新的）代码，需要进行部署。有关如何在分阶段发布环境中执行此操作的指南，请参阅在 Microsoft Azure 中部署 Web 应用程序。
迁移到 PROD 总是有点棘手，因为你总是有一定的风险。因此，最好尽可能自动化此过程，至少排除人为错误。这也是拥有 ACC 环境的另一个原因。在这里，你还会测试你的部署过程，因此你更有可能在 PROD 中正确地执行它。
人非圣贤，孰能无过；但要搞得一团糟，则需要一台计算机。
如何在 VSO 中实现 DTAP？
初始情况
假设你已经创建了你的 Team Project，并将你的第一个代码版本存储在其中（如在 Microsoft Azure 中部署 Web 应用程序中所述），然后继续。
这是 Test 分支（或主分支、trunk 等）。团队中的所有开发人员都对该分支拥有所有访问权限。
创建 ACC 分支
选择 SampleApp/SampleApp 项目（在图片中位于 BuildProcessTemplates 下方），然后单击分支图标。
在弹出的“Branch”对话框中，将目标更改为添加“acceptance”后缀，然后单击 OK。
在“Map”对话框中，指定此分支在你的开发 PC 上的位置。
单击“Map”按钮将创建你的验收分支。DEV 分支会自动复制，因此此时两个分支的内容相同。
创建 PROD 分支的过程也一样。
将你的更改推广到 ACC / PROD
正如我们之前所见，你在开发 PC 上进行一些更改，编译，测试直到一切正常。然后你从 VSO 获取最新版本，这样你就可以获得团队的更改，然后再次测试。如果一切正常，你可以将你的更改移到 DEV（简单地签入你的代码），让它在 DEV 环境中再次构建和测试（通常通过夜间构建或持续集成），然后你想将稳定版本推广到 ACC。
转到“Source Control Explorer”（视图 -> Team Explorer），然后选择 SampleApp DEV 分支。
- 要获取你团队的所有更改，请先获取最新版本：右键单击 SampleApp 文件夹 -> Get Latest Version（获取最新版本）。
- 再次在本地构建和测试你的应用程序，如果出现问题，则修复该问题并返回到 1，直到一切顺利。（我知道，Goto 是禁止的 ;-) ）
- 签入你的更改：右键单击 SampleApp 文件夹 -> Check in pending changes（签入待定更改）-> 输入注释并单击“Check In”（签入）。现在你的更改后的代码已在 DEV 分支中（所以它存在了！）。
- VSO 将再次构建你的代码，并再次运行单元测试。这取决于你的设置（按需、计划、持续集成）。如果出现问题，请返回到 1。在此循环完成后，我们就得到了 DEV 分支中的稳定代码。
- 在“Source Control Explorer”视图中，将 DEV 分支的更改合并到 ACC 分支。右键单击 SampleApp 文件夹 -> Branching and Merging（分支和合并）-> Merge（合并）。选择正确的源分支和目标分支，如以下对话框所示。
单击 next（下一步），然后 Finish（完成）。
- 合并的代码尚未签入 ACC，因此请签入 ACC 分支。
- 与步骤 4 一样，VSO 现在将再次构建和测试你的代码。如果一切顺利，你的用户现在就可以进行验收测试了，你可以执行所有负载测试、性能测试、集成测试以及你喜欢的任何其他测试，然后再决定你的代码是否已准备好移至 PROD。
当你合并 ACC 分支和 PROD 分支时，你可以让 VSO 编译并将新版本部署到暂存服务器，然后在暂存服务器上一切正常后，你可以通过 VIP 交换与当前 PROD 服务器进行交换，这样你的用户就可以开始使用新版本了。这在我之前的文章中有所描述。
关注点
实际实现 DTAP 并非技术挑战。真正的挑战在于组织你的代码和团队来遵循此流程。除非发生紧急情况，否则不应允许例外。使用 VSO，我们可以直接在 TFS 中修改代码，但必须尽快将这些更改追溯到 DEV / ACC / TEST 环境，否则下次合并时你将丢失紧急更改。
对于某些项目来说，这会增加开销，但如果你无法承受网站停机时间，如果你不想因为愚蠢的 bug 而多次发布代码……或者如果你的项目有任何复杂性，那么在项目中设置一些“协议”是一个好主意。
历史
- 这是本文的初始版本。