源代码控制与持续集成的最佳实践

在软件开发过程中，经常需要在不同的环境之间进行代码的迁移和部署。为了确保开发代码不会干扰生产代码，通常会将开发环境与生产环境分离。生产环境是面向客户的，因此它应该受到保护，避免开发者的错误影响到客户。

一种常见的解决方案是保持不同版本的源代码。当然，开发机器上总是有一个版本。在一些项目中，这可能是唯一的版本。而且，会惊讶地发现，在工作过的许多大公司中，情况也是如此。有时，代码会被备份到文件服务器上（通常是像"MySources.20150315.zip"这样的ZIP文件），这确实提供了一些版本控制功能，但它缺乏如差异比较、轻松合并等功能。

更好的解决方案是使用源代码控制系统，如Git、Subversion或Microsoft Team Foundation Server (TFS)。在本文中，将使用TFS在线版，目前它被称为Visual Studio Online (VSO)。如果不知道在说什么，那么请参考之前关于这个主题的文章：。

本文还将解释如何在VSO中设置团队项目，这是将在本文中构建的基础。

什么是DTAP？

希望确保源代码始终安全，可以以受控的方式应用更改，并且可以作为一个团队工作。这听起来像是微软TFS的广告:-) 为了所有这些目的，将使用VSO，因为：

• 它对最多5个用户是免费的，之后的价格仍然非常合理。
• 它托管在云中，这保证了源代码存储得很好，并且为自动备份。
• 它还允许自动构建和测试代码，如果愿意，还可以自动部署。

DTAP代表开发（Development）、测试（Test）、验收（Acceptance）和生产（Production）。这是使代码安全地进化到生产代码的一种方式。让更详细地看看DTAP的含义。

通常在开发PC上开始一个项目，在那里将准备第一个（不完整的）版本。当代码被检入时，将继续工作和本地测试，并时不时地检入代码。通常，希望在完成一个功能时检入代码。或者如果写了bug（当然永远不会这样做），在修复bug后检入代码。

现在处于“在机器上它有效”的阶段。

大多数开发者（包括）会避免将这个版本存储在源代码控制中，只是因为它还没有完成。但这是一种错误的反应：一旦已经有了*某些东西*，希望代码是安全的。而且，团队中可能有其他成员也想在这个项目上工作。这就是为什么在TFS中创建了TEST分支。这是将存储代码的地方。根据所在的团队，可能有一些规则，例如：

• 代码必须在检入之前编译。这是最严格的最低要求。不想成为其他团队成员在项目中获取最新更改后追赶的那个人。
• 测试必须成功运行。在一些环境中，这个条件可能会放宽。在TFS上的自动构建过程中，构建完成后将运行测试，并将测试结果输出。但同样，不想成为破坏构建或使测试失败的那个人。

当在团队中工作时，其他人也会在工作的部分同时更改代码。所以在检入代码之前，最好先获取最新的更改，并再次构建/测试解决方案。这将确保不会因为代码不兼容而破坏构建。不想成为破坏构建/测试的那个人！

记住：如果不在源代码控制中，它就不存在。

当（和测试人员）对测试环境中的代码感到满意时，可以将更改与TFS中的验收（ACC）分支合并。可以让TFS构建也将代码自动部署到ACC服务器，以便用户可以验证所做的工作。如果需要应用更改，应该首先在开发PC（D）上进行，然后将它们移动到TEST分支，在那里它们将被自动构建和测试，当一切都好时，将它们合并回ACC分支。

通常在ACC中，不会再测试功能，因为已经在TEST中完成了。现在想专注于更高的负载，数据量增加时会发生什么，等等。所以这就是性能和负载测试将进行的地方。确保有真实数据的一种方法是将PROD数据库复制到ACC环境并在这些数据库上进行测试。如果不存储敏感数据，这是可以的。否则，可能会遇到一些隐私问题。

当用户满意（所以验收测试是OK的），将从ACC到PROD进行同样的练习。从那时起，将在PROD分支中拥有（更新的）代码，需要部署。参考了解如何在分阶段发布环境中进行部署。

转向PROD总是有点尴尬，因为总是在这里承担一些风险。所以最好尽可能自动化这个过程，至少排除人为错误。这也是拥有ACC环境的另一个原因。这就是测试部署过程的地方，所以在PROD中正确执行的机会要大得多。

犯错是人类的天性，但要彻底搞砸就需要一台计算机。

如何在VSO中实现DTAP？

假设已经创建了团队项目，并将第一版代码存储在其中（如中所解释的），并从这里继续。

这是测试分支（或主分支，树干，...）。团队中的所有开发者都可以访问这个分支。

选择SampleApp/SampleApp项目（在图像中这在BuildProcessTemplates下方），然后点击分支图标。

在弹出的“分支”对话框中，将目标更改为带有“acceptance”后缀，然后点击确定。

在“映射”对话框中，指定这个分支将在开发PC上的位置。点击“映射”按钮将创建验收分支。DEV分支会自动复制，所以此时，两个分支具有相同的内容。

创建PROD分支的方式完全相同。

如前所述，在开发PC上进行一些更改，编译，测试，直到一切正常。然后从VSO获取最新版本，所以有团队的更改，再次测试。如果一切顺利，可以将更改移动到DEV（简单地检入代码），在DEV环境中再次构建和测试（通常是夜间构建或持续集成），然后希望将稳定版本提升到ACC。

转到“源代码控制资源管理器”（查看->团队资源管理器），并选择SampleApp DEV分支。

要获取团队的所有更改，请首先获取最新版本：右键单击SampleApp文件夹->获取最新版本

再次在本地构建和测试应用程序，如果出现问题，那么修复问题并回到第1步，直到一切顺利。（知道，Goto是禁止的；-））

检入更改：右键单击SampleApp文件夹->检查入待处理的更改->输入注释并点击“检入”。现在更改后的代码在DEV分支中（所以它存在！）

VSO将再次构建代码，并再次运行它的单元测试。这取决于设置何时发生（按需，计划，持续集成）。如果出现问题，回到第1步。在这个循环之后，如果完成，在DEV分支中有稳定的代码。

在“源代码控制资源管理器”视图中，将更改从DEV分支合并到ACC分支。右键单击SampleApp文件夹->分支和合并->合并。选择正确的源和目标分支，如下所示的对话框：

点击下一步，然后完成。合并后的代码尚未检入到ACC，所以检入ACC分支。

如步骤4所述，VSO现在将再次构建和测试代码。如果一切顺利，用户现在准备好进行验收测试，可以执行所有负载测试、性能测试、集成测试以及喜欢做的任何其他测试，然后再决定代码是否准备好移动到PROD。

当将ACC分支与PROD分支合并时，可以让VSO编译并部署这个新版本到一个暂存服务器，然后当暂存服务器上一切运行良好时，可以与当前的PROD服务器进行VIP交换，用户可以开始使用新版本。这在之前的文章中有所描述。

感兴趣的点

实际上实施DTAP并不是一个技术挑战。真正的挑战是组织代码和团队遵循这个流程。除非有紧急情况，否则不应允许例外。使用VSO，可以直接在TFS中更改代码，但这些更改必须尽快适应DEV/ACC/TEST环境，否则将在下一次合并时丢失紧急更改。