我知道这已经被问到了,但是我们真的想拒绝任何提交文件的尝试,这些文件会破坏trunk中的项目.拒绝已提交文件的决定基于正在提交的文件所属的项目构建过程的结果.我知道在预提交阶段,无法同时访问存储库,但这对我们来说不是问题,因为我们的构建非常快,我们可以容忍任何延迟.
有没有工具可以达到我们想要的效果？请注意,有必要重新编译整个项目单元,而不仅仅是要提交的单个文件.
如果不能以任何合理的方式完成,那么是否可以在后提交时构建代码,然后在构建步骤失败的情况下立即回滚？哈德森或其他工具可以配置为我们想要的吗？
即使你的构建很快.假设您可以在90秒内构建整个项目.你希望人们每次提交代码都等待90秒吗？可能发生的事情是,人们只会做更少的提交,做出更大的改变,并导致更多的错误.
首先要意识到做出错误的修改不是世界末日.如果您在早期发现问题,则可以轻松恢复更改.这里的关键是早期检测.
如果您还没有,请使用像Jenkins这样的持续集成系统.每当有人提交代码更改时,Jenkins都会进行构建.如果构建速度与您声明的速度一样快,那么当更改破坏构建时,您将在几分钟内收到通知.如果你愿意,你甚至可以让詹金斯恢复变革.我们的理念是开发人员有10分钟的时间来解决问题,或者还原他们的变化.然后,我们把它们放在栅栏里,用烂番茄去皮.(实际上,人力资源部门不会让我们这样做.)
其次,设置易于遵循的标准,允许开发人员确保他们的更改将起作用.我们有一些基本的:
这使我可以轻松地在Jenkins服务器上设置构建.而且,更重要的是,它使开发人员可以轻松使用Jenkins将用于构建的相同构建系统.如果他们可以构建它,Jenkins可以构建它.
接下来,您必须改变您的发展文化.打破构建很糟糕.一旦完成,Jenkins将公开羞辱任何破坏构建的开发人员.我看到一家商店设有红绿灯.如果Jenkins构建破了,那些灯会变红.发生这种情况时,这是一件大事.经理们出来想知道发生了什么.当我在那里时,那些灯永远不会变红.
当然,能够运行构建是软件中的第一步.这是一个很小的婴儿步骤 - 甚至可能是爬行.不,甚至不是,这是六个月大婴儿第一次蠕动的版本.如果破碎的构建是您所在地区的主要问题,那么您就会遇到非常严重的问题.
除了确保编译所有内容之外,下一步是确保代码遵循编码标准并且代码不会做一些可能不好的事情.在Java世界中,它针对代码运行Checkstyle,Findbugs和PMD.詹金斯允许我发布漂亮的图表,向我展示这些程序的结果.我们还收集所有编译警告和JavaDoc错误并绘制图表.如果来自任何这些进程的警告太多,我们甚至可以设置Jenkins使构建失败.您的代码可能会编译,但由于技术不当,构建失败.
接下来是单元测试.在Java世界中,它是JUnit,Jenkins再次显示结果.如果任何JUnit测试失败,我们将失败.如果您的基本界面不好,那么拥有良好的构建并没有多大帮助.
然后,有代码覆盖率.我们的代码有多少是经过单元测试的.我们使用JaCoCo.我们不会因为低代码覆盖率而失败,但我们确实对开发人员施加压力以改善代码覆盖率.最后,我们可以做其他测试.我们部署并运行自动化功能和系统测试.
开发人员所做的每一次更改都会一直受到单元测试的影响.这是我非常喜欢Java的一个方面,我认为Java开发领先于Java.典型的Java构建可以在几分钟内完成.在我们无法进行构建的情况下很少见,并且在10分钟内完成所有单元测试.任何问题都可以及早发现并及早修复.并且,所有问题都在Jenkins公开展示.我们看到谁破坏了构建或导致单元测试失败.我们看到谁有需要修复的编译器警告,或者做了一些糟糕的编码练习.
而且因为我给开发人员提供了Jenkins用于构建的相同工具集,所以他们可以很容易地看到Jenkins会看到的内容.他们也可以运行单元测试和代码测试.没有理由他们提交的代码会导致更多问题而不是解决问题.
这是您取得巨大进步的地方:改善发展文化,关注他们正在做的事情,并为不良做法发出亮点.
在开发之前设置障碍 - 比如让开发人员在每次提交后等待90秒以确保他们的更改构建 - 构建怨恨并且通常会适得其反.你不再是团队的一员,而是建立警察,将每个人视为潜在的嫌疑人.相反,与开发人员合作,让他们相信你想要的是他们的利益.一旦他们看到,他们将与您合作,您的整个开发周期运行得更顺畅.