I've been doing build engineering (among other things) for 16 years. I am a strong believer in build-early, build-often, continuous integration. So the first thing I do with a project is establish how it will be built (Java: Ant or Maven; .NET: NAnt or MSBuild) and how it will be managed (Subversion or some other version control). Then I'll add Continuous Integration (CruiseControl or CruiseControl.NET) depending upon the platform, then let the other developers loose.
As the project grows, and the need for reports and documentation grows, eventually the builds will take longer to run. At that point I'll split the builds into continuous builds (run on checkin) that only compile and run unit tests and daily builds that build everything, run all the reports, and build any generated documentation. I may also add a delivery build that tags the repository and does any additional packaging for a customer delivery. I'll use fine-grained build targets to manage the details, so that any developer can build any part of the system -- the Continuous Integration server use the exact same build steps as any developer. Most importantly, we never deliver a build for testing or a customer that wasn't built using the build server.
That's what I do -- here's why I do it (and why you should too):
Suppose you have a typical application, with multiple projects and several developers. While the developers may start with a common, consistent development environment (same OS, same patches, same tools, same compilers), over the course of time their environments will diverge. Some developers will religiously apply all security patches and upgrades, others won't. Some developers will add new (maybe better) tools, others won't. Some will remember to update their complete workspace before building; others will only update the part of the project they're developing. Some developers will add source code and data files to the project, but forget to add them to source control. Others will write unit tests that depend upon specific quirks of their environment. As a consequence, you'll quickly see the ever-popular "Well, it builds/works on my machine" excuses.
By having a separate, stable, consistent, known-good server for building your application, you'll easily discover these sorts of problems, and by running builds from every commit, you'll be able to pinpoint when a problem crept into the system. Even more importantly, because you use a separate server for building and packaging your application, it will always package everything the same way, every time. There is nothing worse than having a developer ship a custom build to a customer, have it work, and then have no idea how to reproduce the customizations.
When you're using source control, sometimes one programmer accidentally checks in something that breaks the build. For example, they've added a new source file, and everything compiles fine on their machine, but they forgot to add the source file to the code repository. So they lock their machine and go home, oblivious and happy. But nobody else can work, so they have to go home too, unhappy.
Breaking the build is so bad (and so common) that it helps to make daily builds, to insure that no breakage goes unnoticed. On large teams, one good way to insure that breakages are fixed right away is to do the daily build every afternoon at, say, lunchtime. Everyone does as many checkins as possible before lunch. When they come back, the build is done. If it worked, great! Everybody checks out the latest version of the source and goes on working. If the build failed, you fix it, but everybody can keep on working with the pre-build, unbroken version of the source.
On the Excel team we had a rule that whoever broke the build, as their "punishment", was responsible for babysitting the builds until someone else broke it. This was a good incentive not to break the build, and a good way to rotate everyone through the build process so that everyone learned how it worked.
Though I haven't got an opportunity to make daily builds, I'm a great fan of it.
To summarize, you want to build and test as early and often as possible to spot errors immediately so they can be fixed while what you were trying to achieve when you caused them is still fresh in your mind.
In my personal experience, it's a matter of Quality Control: every time code (or tests, which can be seen as a form of requirements) are modified, bugs might be creeping in. To ensure quality you should make a fresh build of the product as it would be shipped and perform all the tests available. The more often this is done, the less likely bugs will be allowed to form a colony. Therefore, daily (nightly) or continuous cycles are preferred.
In addition, whether you restrict access o your project to developers or a larger group of users, a nightly build enables everyone to be on the 'latest version', minimizing the pain of merging their own contributions back into the code.
You want to do builds on a regular schedule in order to catch problems with integration of code between developers. The reason you want to do this nightly, as opposed to weekly or on some longer schedule, is that the longer you wait to discover these kinds of problems, the more difficult it will be to resolve them. The practice of doing a build on every check in (Continuous Integration) is just taking the nightly build process to a logical extreme.
The side benefit of having a repeatable build process is important in the long run as well. If you work on a team where there are multiple projects going on, then at some point you will need to be able to easily recreate an old build, perhaps for creating a patch. :(
The more you can automate the build process, the more time you will save for each subsequent build. It also takes the build process itself off of the critical path of delivering the final product, which should make your manager happy. :)
It also depends on the size and structure of the team(s) working on your project. If there are different teams relying on each others API, it may make a lot of sense to have nightly builds for frequent integration. If you're hacking away with only one or two team mates it may or may not be worth it.
Depending on the complexity of your product continuous integration may or may not be able run a full test suite.
Imagine Cisco testing a router with the literally 1000s of different setups to test. To run a full test suite on some products takes time. Sometimes weeks. So you need builds for different purposes. A nightly build can be the basis for a more thorough test suite.
Any build automation is better than no build automation :-)
Personally, I prefer daily builds - that way if the build doesn't work then everyone is around to get it fixed.
In fact, if at all possible then Continuous Integration builds are the way to go (i.e. a build on every check-in) as that minimizes the amount of change between a build and so makes it easy to tell who broke the build and also easy to fix the build.
Well ... I guess it depends a lot on your project, of course. If it's just your hobby project, with no releases, no dependencies, and noone but you submitting code, it might be overkill.
If, on the other hand, there's a team of developers all submitting code, automatic nightly builds will help you ensure the quality of the code in the repository. If someone does something that "breaks the build" for all others, it will quickly be noticed. It is possible to break the build without noticing, for instance by forgetting to add a new file to the repository, and nightly builds in a centralized location will detect these quite quickly.
There are of course other possible benefits, I'm sure others will supply them. :)
Nightly builds are only necessary for significantly large projects (when it takes too long to build it often throughout the day). If you have a small project that does not take long to build you can build it as you get functional pieces of code done so that you know that you did not mess anything up in the procees. However, with larger projects this is not possible so it is important to build the project just so that you know that everything is still in working order
Nightly builds aren't always necessary - I think they're only really useful on big projects. But if you're on a big project, a nightly build is a good way of checking that everything is working - you can run all your tests (unit tests, integration tests), build all your code - in short, verify that nothing is broken in your project.
If you've got a smaller project your build and test times will be shorter so you can probably afford to do more regular builds.
Nightly builds are ideal for performing static code analysis (see qalab and the projects it collects stats from if you are in java world). Unfortunately, this is something that's rarely done.
You should do nightly builds to ensure that your codebase stays healthy.
A side effect of doing nightly builds is that it forces the team to create and maintain a fully automated build script. This helps to ensure that your build process is documented and repeatable.
Automated builds are good at finding the following problems:
Somebody checked in something that breaks stuff.
Somebody forgot to check in a necessary file or change.
Your build scripts no longer work.
Your build machine is broken.
Doing this nightly ensures that you catch such problems within 24 hours of when they occur. That is preferable to finding all the problems 24 hours before you are supposed to deliver the software.
You should also, of course, have automated unit tests that are run for each nightly build.
发布评论
评论（16）
我从事建筑工程（以及其他工作）已有 16 年了。 我坚信早期构建、经常构建、持续集成。 因此，我对项目所做的第一件事就是确定如何构建它（Java：Ant 或 Maven；； NAnt 或 MSBuild）以及如何它将被管理（Subversion 或其他版本控制）。 然后我将添加持续集成（CruiseControl 或 CruiseControl.NET）取决于平台，然后让其他开发人员放松。
随着项目的发展以及对报告和文档的需求的增长，最终构建将需要更长的时间来运行。 那时，我将把构建分成仅编译和运行单元测试的连续构建（在签入时运行）和构建所有内容、运行所有报告并构建任何生成的文档的每日构建。 我还可以添加一个交付构建来标记存储库并为客户交付进行任何其他打包。 我将使用细粒度的构建目标来管理细节，以便任何开发人员都可以构建系统的任何部分——持续集成服务器使用与任何开发人员完全相同的构建步骤。 最重要的是，我们从不交付用于测试的构建或未使用构建服务器构建的客户。
这就是我所做的——这就是我这样做的原因（以及为什么您也应该这样做）：
假设您有一个典型的应用程序，包含多个项目和多个开发人员。 虽然开发人员可能会从通用、一致的开发环境（相同的操作系统、相同的补丁、相同的工具、相同的编译器）开始，但随着时间的推移，他们的环境将会有所不同。 一些开发人员会认真地应用所有安全补丁和升级，而其他开发人员则不会。 一些开发人员会添加新的（也许更好）工具，而其他开发人员则不会。 有些人会记得在构建之前更新他们的完整工作空间； 其他人只会更新他们正在开发的项目的一部分。 有些开发人员会将源代码和数据文件添加到项目中，但忘记将它们添加到源代码管理中。 其他人将根据其环境的特定怪癖编写单元测试。 因此，您很快就会看到流行的“嗯，它在我的机器上构建/工作”的借口。
通过使用单独的、稳定的、一致的、已知良好的服务器来构建应用程序，您将轻松发现此类问题，并且通过从每次提交运行构建，您将能够查明问题何时渗透到系统中。 更重要的是，因为您使用单独的服务器来构建和打包应用程序，所以它每次都会以相同的方式打包所有内容。 没有什么比开发人员向客户交付定制版本、让它正常工作、然后不知道如何重现定制更糟糕的了。
I've been doing build engineering (among other things) for 16 years. I am a strong believer in build-early, build-often, continuous integration. So the first thing I do with a project is establish how it will be built (Java: Ant or Maven; .NET: NAnt or MSBuild) and how it will be managed (Subversion or some other version control). Then I'll add Continuous Integration (CruiseControl or CruiseControl.NET) depending upon the platform, then let the other developers loose.
As the project grows, and the need for reports and documentation grows, eventually the builds will take longer to run. At that point I'll split the builds into continuous builds (run on checkin) that only compile and run unit tests and daily builds that build everything, run all the reports, and build any generated documentation. I may also add a delivery build that tags the repository and does any additional packaging for a customer delivery. I'll use fine-grained build targets to manage the details, so that any developer can build any part of the system -- the Continuous Integration server use the exact same build steps as any developer. Most importantly, we never deliver a build for testing or a customer that wasn't built using the build server.
That's what I do -- here's why I do it (and why you should too):
Suppose you have a typical application, with multiple projects and several developers. While the developers may start with a common, consistent development environment (same OS, same patches, same tools, same compilers), over the course of time their environments will diverge. Some developers will religiously apply all security patches and upgrades, others won't. Some developers will add new (maybe better) tools, others won't. Some will remember to update their complete workspace before building; others will only update the part of the project they're developing. Some developers will add source code and data files to the project, but forget to add them to source control. Others will write unit tests that depend upon specific quirks of their environment. As a consequence, you'll quickly see the ever-popular "Well, it builds/works on my machine" excuses.
By having a separate, stable, consistent, known-good server for building your application, you'll easily discover these sorts of problems, and by running builds from every commit, you'll be able to pinpoint when a problem crept into the system. Even more importantly, because you use a separate server for building and packaging your application, it will always package everything the same way, every time. There is nothing worse than having a developer ship a custom build to a customer, have it work, and then have no idea how to reproduce the customizations.
当我看到这个问题时，首先我搜索了Joel Spolsky的答案。 有点失望，所以我打算在这里添加它。
希望每个人都了解乔尔职业测试。
来自他的博客 Joel 测试：改进代码的 12 个步骤
虽然我没有机会进行日常构建，但我非常喜欢它。
还是不相信？ 查看每日构建是您的朋友！！
When I saw this question, first I searched for Joel Spolsky's answer. Bit disappointed, so I planned to add it here.
Hope everyone is aware of Joel Test on Careers.
From his blog on The Joel Test: 12 Steps to Better Code
Though I haven't got an opportunity to make daily builds, I'm a great fan of it.
Still not convinced? Check out the brief here in Daily Builds Are Your Friend!!
实际上你不需要，你应该想要的是持续集成和自动测试（这比夜间构建更进一步）。
如果您有任何疑问，您应该阅读Martin Fowler 撰写的有关持续集成的文章。
总而言之，您希望尽可能早、尽可能频繁地构建和测试，以便立即发现错误，以便能够修复这些错误，同时您在造成这些错误时想要实现的目标仍然记忆犹新。
You don't actually, what you should be wanting is Continuous Integration and automatic testing (which is a step further than nightly builds).
If you are in any doubt you should read this article by Martin Fowler about Continuous Integration.
To summarize, you want to build and test as early and often as possible to spot errors immediately so they can be fixed while what you were trying to achieve when you caused them is still fresh in your mind.
实际上，我建议您每次签入时都进行构建。换句话说，我建议建立一个持续集成系统。
这种系统的优点和其他详细信息可以在Fowler 的文章和维基百科条目以及其他地方。
根据我个人的经验，这是质量控制的问题：每次修改代码（或测试，可以看作是一种需求形式）时，错误可能会悄悄出现。为了确保质量，您应该对产品进行全新构建因为它将被运送并执行所有可用的测试。 这样做的次数越多，错误形成群体的可能性就越小。 因此，每日（每晚）或连续循环是优选的。
此外，无论您将项目的访问限制为开发人员还是更大的用户组，夜间构建都可以让每个人都使用“最新版本”，从而最大限度地减少将自己的贡献合并回代码的痛苦。
I'd actually recommend to do builds every time you check in. In other words, I'd recommend setting up a Continuous Integration system.
The advantages of such a system and other details can be found in Fowler's article and on the Wikipedia entry among other places.
In my personal experience, it's a matter of Quality Control: every time code (or tests, which can be seen as a form of requirements) are modified, bugs might be creeping in. To ensure quality you should make a fresh build of the product as it would be shipped and perform all the tests available. The more often this is done, the less likely bugs will be allowed to form a colony. Therefore, daily (nightly) or continuous cycles are preferred.
In addition, whether you restrict access o your project to developers or a larger group of users, a nightly build enables everyone to be on the 'latest version', minimizing the pain of merging their own contributions back into the code.
您希望按定期进行构建，以便发现开发人员之间代码集成的问题。 您想要每晚这样做的原因是，您等待发现此类问题的时间越长，解决它们就越困难。 在每次签入时进行构建（持续集成）的做法只是将夜间构建过程推向了逻辑的极端。
从长远来看，可重复构建过程的附带好处也很重要。 如果您在一个正在进行多个项目的团队中工作，那么在某些时候您将需要能够轻松地重新创建旧版本，也许是为了创建补丁。 :(
构建过程自动化程度越高，为每个后续构建节省的时间就越多。它还使构建过程本身脱离了交付最终产品的关键路径，这应该会让您的经理感到高兴。:)
You want to do builds on a regular schedule in order to catch problems with integration of code between developers. The reason you want to do this nightly, as opposed to weekly or on some longer schedule, is that the longer you wait to discover these kinds of problems, the more difficult it will be to resolve them. The practice of doing a build on every check in (Continuous Integration) is just taking the nightly build process to a logical extreme.
The side benefit of having a repeatable build process is important in the long run as well. If you work on a team where there are multiple projects going on, then at some point you will need to be able to easily recreate an old build, perhaps for creating a patch. :(
The more you can automate the build process, the more time you will save for each subsequent build. It also takes the build process itself off of the critical path of delivering the final product, which should make your manager happy. :)
它还取决于从事您的项目的团队的规模和结构。 如果有不同的团队依赖彼此的 API，那么每晚构建一次以进行频繁集成可能会很有意义。 如果你只和一两个队友一起进行黑客攻击，这可能值得也可能不值得。
It also depends on the size and structure of the team(s) working on your project. If there are different teams relying on each others API, it may make a lot of sense to have nightly builds for frequent integration. If you're hacking away with only one or two team mates it may or may not be worth it.
根据产品的复杂性，持续集成可能会也可能不会运行完整的测试套件。
想象一下，思科测试一台路由器时需要进行数千种不同的设置。 对某些产品运行完整的测试套件需要时间。 有时是几周。 因此，您需要针对不同目的进行构建。 每晚构建可以成为更彻底的测试套件的基础。
Depending on the complexity of your product continuous integration may or may not be able run a full test suite.
Imagine Cisco testing a router with the literally 1000s of different setups to test. To run a full test suite on some products takes time. Sometimes weeks. So you need builds for different purposes. A nightly build can be the basis for a more thorough test suite.
我认为它们非常重要，尤其是对于超过 1 人的项目。 团队需要尽快知道是否有人：
I think they are very important especially on projects with more than 1 person. The team needs to know ASAP if someone:
任何构建自动化都比没有构建自动化好:-)
就我个人而言，我更喜欢每日构建 - 这样，如果构建不起作用，那么每个人都会来修复它。
事实上，如果可能的话，持续集成构建是可行的方法（即每次签入时都进行构建），因为这可以最大限度地减少构建之间的更改量，因此可以轻松判断谁破坏了构建，也很容易修复构建。
Any build automation is better than no build automation :-)
Personally, I prefer daily builds - that way if the build doesn't work then everyone is around to get it fixed.
In fact, if at all possible then Continuous Integration builds are the way to go (i.e. a build on every check-in) as that minimizes the amount of change between a build and so makes it easy to tell who broke the build and also easy to fix the build.
嗯……当然，我想这在很大程度上取决于您的项目。 如果这只是您的业余爱好项目，没有版本，没有依赖项，除了您之外没有人提交代码，那么它可能有点矫枉过正。
另一方面，如果有一个开发团队都在提交代码，则自动夜间构建将帮助您确保存储库中代码的质量。 如果有人做了一些“破坏构建”的事情，很快就会被注意到。 有可能在不注意的情况下破坏构建，例如忘记将新文件添加到存储库，并且集中位置的夜间构建将很快检测到这些。
当然还有其他可能的好处，我相信其他人会提供它们。 :)
Well ... I guess it depends a lot on your project, of course. If it's just your hobby project, with no releases, no dependencies, and noone but you submitting code, it might be overkill.
If, on the other hand, there's a team of developers all submitting code, automatic nightly builds will help you ensure the quality of the code in the repository. If someone does something that "breaks the build" for all others, it will quickly be noticed. It is possible to break the build without noticing, for instance by forgetting to add a new file to the repository, and nightly builds in a centralized location will detect these quite quickly.
There are of course other possible benefits, I'm sure others will supply them. :)
仅对于非常大的项目才需要每晚构建（当需要在一天中构建它的时间太长时）。 如果您有一个不需要很长时间构建的小项目，您可以在完成功能代码片段后构建它，这样您就知道您没有在过程中搞砸任何事情。 但是，对于较大的项目，这是不可能的，因此构建项目非常重要，这样您就知道一切仍然正常工作
Nightly builds are only necessary for significantly large projects (when it takes too long to build it often throughout the day). If you have a small project that does not take long to build you can build it as you get functional pieces of code done so that you know that you did not mess anything up in the procees. However, with larger projects this is not possible so it is important to build the project just so that you know that everything is still in working order
有几个原因，其中一些比其他更适用
There are several reasons, some will be more applicable than others
每晚构建并不总是必要的 - 我认为它们只对大型项目真正有用。 但是，如果您正在进行一个大型项目，则每晚构建是检查一切是否正常运行的好方法 - 您可以运行所有测试（单元测试、集成测试），构建所有代码 - 简而言之，验证是否没有任何问题你的项目坏了。
如果您的项目较小，您的构建和测试时间将会更短，因此您可能有能力进行更多的常规构建。
Nightly builds aren't always necessary - I think they're only really useful on big projects. But if you're on a big project, a nightly build is a good way of checking that everything is working - you can run all your tests (unit tests, integration tests), build all your code - in short, verify that nothing is broken in your project.
If you've got a smaller project your build and test times will be shorter so you can probably afford to do more regular builds.
每晚构建非常适合执行静态代码分析（如果您在 Java 世界中，请参阅 qalab 及其从中收集统计信息的项目）。 不幸的是，这是很少有人做的事情。
Nightly builds are ideal for performing static code analysis (see qalab and the projects it collects stats from if you are in java world). Unfortunately, this is something that's rarely done.
您应该每晚进行构建，以确保您的代码库保持健康。
每晚构建的一个副作用是它迫使团队创建和维护完全自动化的构建脚本。 这有助于确保您的构建过程有记录且可重复。
自动化构建擅长发现以下问题：
每晚执行此操作可确保您在此类问题发生后 24 小时内发现它们。 这比在交付软件之前 24 小时发现所有问题要好。
当然，您还应该为每个夜间构建运行自动化单元测试。
You should do nightly builds to ensure that your codebase stays healthy.
A side effect of doing nightly builds is that it forces the team to create and maintain a fully automated build script. This helps to ensure that your build process is documented and repeatable.
Automated builds are good at finding the following problems:
Doing this nightly ensures that you catch such problems within 24 hours of when they occur. That is preferable to finding all the problems 24 hours before you are supposed to deliver the software.
You should also, of course, have automated unit tests that are run for each nightly build.
我个人发现持续集成比夜间构建更好：
我什至在一个人的
项目中使用它，令人惊奇的是您能够如此快速地暴露问题并立即解决它们。
I've personally found continuous integration to be better than nightly builds:
http://en.wikipedia.org/wiki/Continuous_integration
I even use it on one man projects, it's amazing how fast you can expose issues and take care of them right there.