以 SVN 中的预提交为基础 [英] Build on pre-commit in SVN

问题描述

我知道这已经被问到了，但我们真的很想拒绝任何提交文件的尝试，这会破坏主干中的项目.拒绝提交文件的决定是基于正在提交的文件所属项目的构建过程的结果.我知道在预提交阶段无法同时访问存储库，但这对我们来说不是问题，因为我们的构建速度非常快，而且我们可以容忍任何延迟.

I know this has been asked already, but we would really like to reject any attempt to commit files which would break a project in trunk. The decision to reject the committed files is based on the result of the building process of the project the files being committed belong to. I know that during the pre-commit phase the repository cannot be accessed concurrently, but this is not a problem for us since our builds are really fast and we can tolerate any delay involved.

有什么工具可以实现我们想要的?请注意，需要重新编译整个项目单元，而不仅仅是提交的单个文件.

Are there any tools to achieve what we want? Note that it will be necessary to recompile the whole project unit, not just the single files being committed.

如果这不能以任何合理的方式完成，是否可以在提交后构建代码，然后在构建步骤失败时立即回滚?可以配置 Hudson 或其他工具来执行我们想要的操作吗?

If that cannot be done in any reasonable way, would it be possible to do the build the code during post-commit followed by an immediate rollback in case of failures on the building step? Can Hudson or other tools be configured to do what we want?

推荐答案

即使您的构建速度很快.假设您可以在 90 秒内构建整个项目.您是否希望人们每次提交代码时都等待 90 秒?可能会发生的情况是，人们只会做更少的提交，进行更大的更改，并导致更多错误.

Even if your build is fast. Let's say you can build the entire project in 90 seconds. Do you want people to wait 90 seconds every time they commit their code? What may happen is that people will simply do less commits, make bigger changes, and cause more errors.

首先要意识到提交错误的修订并不是世界末日.如果您及早发现问题，您可以轻松恢复更改.这里的关键是早期检测.

First realize that committing a bad revision is not the end of the world. If you catch the problem early on, you can easily revert the change. The key here is early detection.

如果您还没有，请获取一个持续集成系统，例如詹金斯.每当有人对代码进行更改时，Jenkins 都会进行构建.如果构建与您声称的一样快，当更改破坏构建时，您将在几分钟内收到通知.如果您愿意，您甚至可以让 Jenkins 恢复更改.我们的理念是开发人员有 10 分钟的时间来解决问题，或恢复他们的更改.然后，我们把它们放在寨子里，用腐烂的西红柿给它们剥皮.(实际上，HR 不会让我们这样做.)

If you don't already have one, get a Continuous Integration system like Jenkins. Whenever someone commits a change in the code, Jenkins will do a build. If the builds are as fast as you claim, you will be notified in a couple of minutes when a change breaks the build. You can even have Jenkins revert the change if you so desire. Our philosophy is that the developer has 10 minutes to fix the problem, or revert their change. Then, we put them in stockades and pelt them with rotten tomatoes. (Actually, HR won't let us do that.)

其次，设置易于遵循的标准，允许开发人员确保他们的更改有效.我们有一些基本的:

Second, setup easy to follow standards that allow developers to make sure that their changes will work. We have a few basic ones:

• 我们定义了一组所有开发人员都应该拥有的基本工具(Java、Ant、Subversion).
• 除了这三个基本工具之外，所有其他工具和所需部件都放置在工作目录中并签入 Subversion.
• 不需要特殊的环境设置.构建不需要配置等
• 构建完成后，所有构建的对象都在工作目录中完成.

这让我可以轻松地在我们的 Jenkins 服务器上设置构建.而且，更重要的是，它使开发人员可以轻松使用 Jenkins 用于构建的相同构建系统.如果他们能构建它，Jenkins 就能构建它.

This makes it easy for me to setup builds on our Jenkins server. And, more importantly, it makes it easy for developers to use the same build system Jenkins will use for the builds. If they can build it, Jenkins can build it.

接下来，您必须改变您的开发文化.破坏构建是不好的.一旦完成，Jenkins 将公开羞辱任何破坏构建的开发人员.我看到的一家商店设置了交通灯.如果 Jenkins 构建坏了，这些灯就会变红.当这种情况发生时，这是一件大事.经理们出来了，想知道发生了什么.当我在那里时，那些灯从未变红.

Next, you have to change your development culture. Breaking a build is bad. Once that is done, Jenkins will publicly shame any developer who broke the build. One shop I saw had traffic lights setup. If a Jenkins build broke, those lights turned red. It's a big deal when that happens. The managers come out and want to know what's going on. Those lights never turned red when I was there.

当然，能够运行构建是软件开发的第一步.这是一个很小的婴儿步骤——甚至可能是爬行.不，甚至不是，这是六个月大婴儿第一次爬行的版本.如果损坏的构建是您所在位置的主要问题，那么您就会遇到非常严重的问题.

Of course, being able to run a build is the very, very first step in software. It is a tiny baby step -- maybe even a crawl. No, not even that, it's the version of a six month old baby's first creep. If broken builds are a major concern at your place, you have very serious problems.

除了确保一切都能编译之外，下一步是确保代码遵循编码标准，并且代码没有做一些可能不好的事情.在 Java 世界中，它针对代码运行 Checkstyle、Findbugs 和 PMD.Jenkins 允许我发布漂亮的图表，向我展示这些程序的结果.我们还收集所有编译警告和 JavaDoc 错误并绘制它们的图表.我们甚至可以设置 Jenkins 使构建失败，如果这些过程中的任何一个有太多警告.您的代码可能会编译，但由于技术不佳导致构建失败.

The next step beyond making sure everything compiles is making sure the code follows coding standard and the code isn't doing something that could be bad. In the Java world, it's running Checkstyle, Findbugs, and PMD against the code. Jenkins allows me to post nice charts showing me the results of these programs. We also gather all compile warnings and JavaDoc errors and graph those. We can even setup Jenkins to fail the build if there are too many warnings from any of these processes. Your code may compile, but the build fails because of bad technique.

接下来是单元测试.在 Java 世界中，它是 JUnit，Jenkins 再次显示结果.如果任何 JUnit 测试失败，我们的构建就会失败.如果你的基本界面很糟糕，那么拥有一个好的构建也没什么好处.

Next is unit testing. In the Java world, it's JUnit and again Jenkins displays the results. We fail builds if any JUnit test fails. It doesn't do much good having a good build if your basic interface is bad.

然后是代码覆盖率.我们有多少代码正在进行单元测试.我们为此使用 JaCoCo.我们不会因为代码覆盖率低而导致构建失败，但我们确实向开发人员施加压力以提高代码覆盖率.最后，我们可以做其他测试.我们部署并运行自动化的功能和系统测试.

Then, there's code coverage. How much of our code is being unit tested. We use JaCoCo for that. We don't fail builds for low code coverage, but we do put pressure on our developers to improve code coverage. Finally, we can do other testing. We deploy, and run automated functional and system tests.

开发人员所做的每一项更改都会一直持续到单元测试.这是我真正喜欢 Java 的地方之一，也是我认为 Java 开发遥遥领先的地方.一个典型的 Java 构建可以在几分钟内完成.我们无法在 10 分钟内完成构建并运行所有单元测试的情况很少见.任何问题都会及早发现并尽早解决.而且，所有问题都在 Jenkins 中公开展示.我们看到谁破坏了构建或导致单元测试失败.我们看看谁收到了需要修复的编译器警告，或者做了一些糟糕的编码实践.

Every change a developer does gets blasted all the way to Unit testing. It's one of the things I really like about Java and where I think Java development is way ahead of the curve. A typical Java build can be done in minutes. It's rare where we can't do a build, and run all unit tests with in 10 minutes. Any problems are caught early and fixed early on. And, all problems are on public display in Jenkins. We see who broke the build or caused a unit test to fail. We see who had compiler warnings they need to fix, or did some bad coding practice.

而且由于我为开发人员提供了与 Jenkins 用于构建的相同工具集，他们可以轻松地看到 Jenkins 将看到的内容.他们也可以运行单元测试和代码测试.他们没有理由提交导致问题多于解决问题的代码.

And because I give the developers the same set of tools that Jenkins uses for its builds, they can easily see what Jenkins will see. They can run the unit tests and the code tests too. There's no reason they commit code which causes more problems than it solves.

这是您取得巨大进步的地方:改进开发文化以关注他们正在做的事情并为不良做法亮灯.

This is where you make great strides: Improving the development culture to care about what they're doing and shining a bright light on bad practices.

在开发前设置障碍——比如让开发人员在每次提交后等待 90 秒以确保他们的更改构建——会引起不满并且通常会适得其反.您不再是团队的一员，而是将每个人都视为潜在嫌疑人的构建警察.相反，与开发人员合作并说服他们你想要的是他们的利益.一旦他们看到这一点，他们就会与您合作，您的整个开发周期就会运行得更加顺畅.

Putting obstacles in front of development -- like making developers wait 90 seconds after each commit to make sure their changes build -- builds resentment and usually backfires. You're no longer part of the team, but the build cop who treats everyone as a potential suspect. Instead, work with developers and convince them that what you want is to their benefit. Once they see that, they'll work with you and your whole development cycle runs much smoother.

这篇关于以 SVN 中的预提交为基础的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！