Joel似乎是think highly of daily builds。对于传统的编译应用程序，我当然可以看到他的理由，但是这与Web开发是平行的吗？或者不是？每天都在为网页应用程序构建方式吗？
有点关于我要求的项目 - 有2个开发人员在Django（Python）Web应用程序上工作。我们有1个SVN仓库。每个开发人员都会维护一个结帐和本地运行的MySQL副本（如果您不熟悉Django，它会捆绑它自己的测试服务器，这与ASP应用程序在Visual Studio中运行的方式很相似）。开发和测试在本地完成，然后提交回存储库。该网站的实际工作副本是一个SVN结帐（我知道SVN导出，它需要很长的时间）。我们最接近'build'的是批处理文件，它在工作副本上运行SVN更新，django位（'manage.py syncdb'），更新搜索引擎缓存（solr），然后重新启动apache。
我想我没有看到的是与web应用程序并行。
你在做一个源代码控制的网页应用程序吗？如果是的话，那是什么样的？
通过Django测试框架，您可以轻松地运行所有Django单元测试作为每晚构建。
这就是我们所做的。
我们还有一些不利用Django特性的普通单元测试，我们也运行这些测试。
即使Python（和Django）不需要编译语言所做的夜间编译/链接/单元测试，但您仍然从“不打破构建”的日常规律中受益。并且每个单元测试每一个周期都是一件好事。
我们正在看Python 2的麻烦。6（它对我们来说非常完美），并使用-3选项运行我们的单元测试，以查看我们正在使用哪些不推荐使用的功能。拥有全套的单元测试可以确保对Python 3兼容性的改变不会破坏构建。并且每晚运行它意味着我们必须是肯定我们正在重构正确。
如果您有正确的流程，持续集成很有用。 TeamCity的从JetBrains公司是一个很好的起点，如果你想建立的熟悉：
http://www.jetbrains.com/teamcity/index.html
有直接涉及到的Django这里一个伟大的文章：
http://www.ajaxline.com/continuous-integration-in-django-project
希望这可以让你开始。
使用动态语言构建的Web应用程序可能不需要“编译”步骤，但仍然可能需要一些“构建”步骤才能使应用程序运行。您的构建脚本可能会安装或升级依赖项，执行数据库迁移，然后运行测试套件以确保代码“干净”w.r.t.存储库中的实际签入版本。或者，您可以将代码副本部署到测试服务器，然后针对新版本运行一组Selenium集成测试，以确保核心网站功能仍然有效。
这可能有助于做一些关于持续集成的主题，这是一个非常有用的做法为web应用开发团队。开发过程越快速和灵活，越需要来自自动化测试和质量指标的定期输入，以确保您在代码的任何损坏版本上快速响亮地失败。
+1是我看到的第一个答案，它将构建过程的非编译方面的想法与持续集成的建议相结合。 FWIW，我已经与CruiseControl为一个webapp好运。 – rmeador 2009-09-18 17:07:54
我已经在使用Hudson进行持续集成方面取得了巨大的成功。通过Redsolo在Python上使用Hudson的详细信息。
几个月前，一些支持continuous deployment的文章引起了网上的轰动。 IMVU有关于他们如何deploy up to 5 times a day的详细信息。
频繁构建（夜间或更频繁，如持续集成）背后的全部想法是立即获得反馈，以减少引入问题和检测之间的时间间隔。所以，只有通过编译，（理想自动化）测试，质量检查等方式才能产生一些反馈意见时，频繁构建才是有用的。没有反馈，就没有真正意义。
如果真的只有你和其他开发人员在工作，每晚构建可能不会给你太多。
我想说每晚构建的Web应用程序相当于中转站点（可以每晚构建）。
如果客户，项目经理和质量保证人员需要能够看到最新的应用程序，但相对稳定的应用程序版本，那么每晚在临时区域建立一个真正的分红就开始支付真正的红利。您的开发人员沙箱（如果您至少与我一样）可能会花费大量时间处于无法使用的状态，因为您正在尝试实现下一个功能。因此，典型的问题是质量保证人员想验证错误是否已修复，或者PM想要检查某项计划的功能是否正确实施，或者客户希望看到您在他们关心的问题上取得了进展关于。如果他们只能访问开发人员的沙箱，那么很可能当他们开始查看时，或者沙箱版本没有运行（因为这意味着./manage.py runserver在某个终端上运行）或者它是由于其他原因而处于断裂状态。这真的会减慢整个团队，浪费很多时间。
这听起来像你没有登台设置，因为你只是自动更新生产版本。如果你是的方式比我（我认为大多数开发人员）更加小心谨慎，并且从不承诺任何不完全防弹的东西，那可能会很好。就我个人而言，我宁愿确保我的作品在达到作品之前通过至少一些其他人的粗略质量保证。
所以，在最后，设置，我的工作：
我想说唯一的缺点（除了一些额外的开销设置夜间暂存版本），它是一个错误验证周转一天。即QA报告软件中的错误（基于查看当天的每晚构建），开发人员修复错误和提交，然后QA必须等到第二天的构建才能检查错误实际上是否已修复。这通常不是什么大问题，因为每个人都有足够的东西继续下去，所以不会影响时间表。当里程碑即将到来，并且我们处于功能冻结，仅限修补程序模式时，我们会更频繁地手动更新分段网站。
+1动态语言的网络应用程序通常不需要“构建”，但强烈建议持续集成测试。 – 2009-09-19 16:01:32