我开始在工作中获得声誉,因为“打破了构建的人”。
问题不在于我正在编写狡猾的代码,但在检查我的修复程序回到源代码控制时,一切都出错了。
我经常做愚蠢的事情,如:
我需要养成一些习惯/工具来阻止这种情况。
您经常做些什么来确保您签入的代码是正确的并且需要进行哪些操作?
修改
我忘了提到这个地方的事情会变得非常混乱。在任何时候,我经常会在同一个代码库中处理两到三件事。当我办理登机手续时,我只想检查其中一件事。
答案 0 :(得分:7)
一些建议:
团队可以做的其他事情是建立一个像David M建议的持续集成服务器,以便尽快并自动发现破坏的构建。
答案 1 :(得分:4)
我通常总是先做一个Get Latest,然后再进行构建。如果构建良好,那么我签入我的代码。
答案 2 :(得分:2)
首先,使用多个工作副本(a.k.a沙箱) - 每个问题一个。因此,如果您已经在一段时间内处理某些复杂功能,并且需要在同一个项目上处理快速错误修复,请查看新的干净工作副本并在那里修复错误。对于每个问题都有独立的工作副本,不会混淆从工作副本提交到reposistory的更改。
其次,在提交更改之前,请始终执行以下三个步骤:
这些应该在任何合并操作之后重复(例如在SVN更新之后)。
答案 3 :(得分:2)
这是我一直在做的事情。我过去使用过ClearCase和CVS进行源代码控制,最近我一直使用Subversion和Visual Studio 2008作为我的IDE。
更改代码并在本地计算机上构建。
确保他们确实修复了有问题的错误。
在本地计算机上运行SVN更新,并重复步骤1和2.
运行自动单元测试以验证它们是否通过。
如果有自动烟雾测试,它会自动测试系统的许多功能,请运行它。验证结果是否正确。
然后转到构建计算机并运行构建脚本。
如果项目的配置发生了变化,这肯定会破坏构建。在构建计算机上执行SVN更新,无论构建脚本是否执行此操作。打开构建计算机的IDE副本,然后执行完整的重建。这将显示构建框是否存在您在计算机上处理但在构建框上没有的任何问题。
如果您可以跟踪您正在处理的所有问题,那么为每个问题保留单独分支的建议也非常好。
答案 4 :(得分:2)
在我的工作场所,此安全网是同行评审。也就是说,让他人在他们的视图上构建,运行和重现您的计算机上的解决方案。
我不能推荐这个。它已经捕获了许多遗漏,可能存在的问题以及其他偶然的垃圾碎片,使其成为这一过程的重要组成部分。更不用说仅仅知道你必须将你的工作放在别人面前才能进入主要分支,这意味着你提高了自己的质量标准。
答案 5 :(得分:1)
过去我在Clear Case中使用分支来帮助解决这个问题。我使用的过程如下。我从未使用过SorceDepot,所以我不知道如何使用它来适应它。
通过创建分支然后将更改合并到不同的视图(我使用合并管理器进行合并),任何未包含或签入的文件都会立即导致问题。这样一切都会在稳定分支上检查时进行测试。
答案 6 :(得分:1)
避免问题的最好方法是使用大多数SCM中提供的钩子(它们肯定在SVN和Mercurial中,我相信它们必须在其他高级SCM中)。将单元测试附加到钩子上,并在每次有人检查代码时使其运行 - 恰好在签入之前。这样你就可以实现两件事:
答案 7 :(得分:1)
我喜欢Windows资源管理器的Tortoise插件。文件图标都标有提交,修改或未添加的图标,这使得查看文件的状态非常容易。我还启用了修改的元数据,因此我可以在列表(详细信息)视图中对已更改的文件进行排序,其中它们起泡到顶部所以我可以看到它们。
我打赌你的SCM有一个Tortoise *插件,我看到一个用于Mercurial和SVN(以及CVS,呃)。我真的希望Mac OS X的Finder能够接受像Tortoise这样的插件,它比在大多数时候打开专用应用程序要容易得多。
答案 8 :(得分:1)
在您签入代码之前,让其他人完成“每次”更改。