Joel 似乎高度评价每日构建。对于传统的编译应用程序，我当然可以看到他的理由，但是这与 Web 开发有何相似之处——或者不是吗？
关于我要求的项目的一些信息——
有 2 名开发人员正在开发 Django (Python) Web 应用程序。我们有 1 个 svn 存储库。每个开发人员都维护一个签出和自己在本地运行的 MySQL 副本（如果您不熟悉 Django，它会与其自己的测试服务器捆绑在一起，就像 ASP 应用程序在 Visual Studio 中运行一样）。开发和测试在本地完成，然后提交回存储库。该网站的实际工作副本是 SVN checkout（我知道 SVN 导出，而且需要很长时间）。我们最接近“构建”的是一个批处理文件，它在工作副本上运行 SVN 更新，执行 django 位（“manage.pysyncdb”），更新搜索引擎缓存（solr），然后重新启动 apache。
我想我没有看到与网络应用程序的相似之处。
您是否正在使用“夜间构建”开发源代码控制的 Web 应用程序 - 如果是这样，那是什么样子的？
Joel seems to think highly of daily builds. For a traditional compiled application I can certainly see his justification, but how does this parallel over to web development -- or does it not?
A bit about the project I'm asking for --
There are 2 developers working on a Django (Python) web app. We have 1 svn repository. Each developer maintains a checkout and thier own copy of MySQL running locally (if you're unfamiliar with Django, it comes bundled with it's own test server, much the way ASP apps can run inside of Visual Studio). Development and testing are done locally, then committed back to the repository. The actual working copy of the website is an SVN checkout (I know about SVN export and it takes too long). The closest we have to a 'build' is a batch file that runs an SVN update on the working copy, does the django bits ('manage.py syncdb'), updates the search engine cache (solr), then restarts apache.
I guess what I don't see is the parallel to web apps.
Are you doing a source controlled web app with 'nightly builds' -- if so, what does that look like?
发布评论
评论（6）
频繁构建（每晚或更频繁，如持续集成）背后的整个想法是获得即时反馈，以减少问题引入和检测之间所花费的时间。因此，只有当您能够通过编译、（理想情况下自动化）测试、质量检查等生成一些反馈时，频繁构建才有用。没有反馈，就没有任何实际意义。
The whole idea behind frequent builds (nightly or more frequent like in continuous integration) is to get immediate feedback in order to reduce the elapsed time between the introduction of a problem and its detection. So, building frequently is useful only if you are able to generate some feedback through compilation, (ideally automated) testing, quality checks, etc. Without feedback, there is no real point.
用动态语言构建的 Web 应用程序可能不需要“编译”步骤，但在运行应用程序时仍然可能涉及许多“构建”步骤。您的构建脚本可能会安装或升级依赖项，执行数据库迁移，然后运行测试套件以确保代码对于存储库中实际签入的版本来说是“干净的”。或者，您可以将代码副本部署到测试服务器，然后针对新版本运行一组 Selenium 集成测试，以确保核心站点功能仍然有效。
阅读一些有关持续集成主题的内容可能会有所帮助，这对于 Web 应用程序开发团队来说是非常有用的实践。您的开发过程越快节奏、越敏捷，您就越需要来自自动化测试和质量指标的定期输入，以确保您在任何损坏的代码版本上快速而大声地失败。
Web applications built in dynamic languages may not require a "compilation" step, but there can still be a number of "build" steps involved in getting the app to run. Your build scripts might install or upgrade dependencies, perform database migrations, and then run the test suite to insure that the code is "clean" w.r.t. the actual checked-in version in the repository. Or, you might deploy a copy of the code to a test server, then run a set of Selenium integration tests against the new version to insure that core site functionality still works.
It may help to do some reading on the topic of Continuous Integration, which is a very useful practice for webapp dev teams. The more fast-paced and agile your development process, the more you need regular input from automated testing and quality metrics to make sure you fail fast and loud on any broken version of the code.
如果真的只有您和另一位开发人员在处理它，则夜间构建可能不会给您带来太多好处。
我想说，相当于每晚构建的网络应用程序将是临时站点（可以每晚构建）。
当您的客户、项目经理和 QA 人员需要能够看到最新但相对稳定的应用程序版本时，每晚构建临时区域开始带来真正的红利。当您为了实现下一个功能而破坏某些东西时，您的开发人员沙箱（至少如果您像我一样）可能会花费大量时间处于不可用状态。因此，典型的问题是 QA 人员想要验证错误是否已修复，或者 PM 想要检查某些计划的功能是否已正确实现，或者客户想要看到您在他们关心的问题上取得了进展关于。如果他们只能访问开发人员沙箱，那么当他们抽出时间查看沙箱版本时，很有可能沙箱版本没有运行（因为这意味着 ./manage.py runserver 已在某个终端中运行）或者正在运行由于其他原因而处于破碎状态。这确实会减慢整个团队的速度并浪费大量时间。
听起来您没有暂存设置，因为您只是自动更新生产版本。如果您比我（我认为大多数开发人员）更加小心和自律，并且从不犯下任何不完全安全的事情，那就没问题了。就我个人而言，我宁愿确保我的作品在投入生产之前至少通过了除我之外的其他人的一些粗略的质量检查。
因此，总而言之，我工作的设置是：
我想说唯一的缺点（除了设置夜间分段构建的一些额外开销之外）是它需要一天的错误验证周转时间。即，QA 报告软件中的错误（基于查看当天的夜间构建），开发人员修复错误并提交，然后 QA 必须等到第二天的构建来检查错误是否确实已修复。这通常不是什么大问题，因为每个人都有足够的事情要做，不会影响日程安排。当一个里程碑即将到来并且我们处于功能冻结、仅修复错误的模式时，我们将对临时站点进行更频繁的手动更新。
If it's really just you and one other developer working on it, nightly builds are probably not going to give you much.
I would say that the web app equivalent of nightly builds would be staging sites (which can be built nightly).
Where nightly builds to a staging area start paying real dividends is when you have clients, project managers, and QA people that need to be able to see an up to date, but relatively stable version of the app. Your developer sandboxes (if you're like me, at least) probably spend a lot of time in an unusable state as you're breaking things trying to get the next feature implemented. So the typical problem is that a QA person wants to verify that a bug is fixed, or a PM wants to check that some planned feature was implemented correctly, or a client wants to see that you've made progress on the issue that they care about. If they only have access to developer sandboxes, there's a good chance that when they get around to looking at it, either the sandbox version isn't running (since it means ./manage.py runserver is up in a terminal somewhere) or it's in a broken state because of something else. That really slows down the whole team and wastes a lot of time.
It sounds like you don't have a staging setup since you just automatically update the production version. That could be fine if you're way more careful and disciplined than I (and I think most developers) am and never commit anything that isn't totally bulletproof. Personally, I'd rather make sure that my work has made it through at least some cursory QA by someone other than me before it hits production.
So, in conclusion, the setup where I work:
I'd say the only downside (besides a bit of extra overhead setting up the nightly staging builds) is that it makes for a day of turnaround on bug verification. ie, QA reports a bug in the software (based on looking at that day's nightly build), developer fixes bug and commits, then QA must wait until the next day's build to check that the bug is actually fixed. It's usually not that much of a problem since everyone has enough stuff going on that it doesn't affect the schedule. When a milestone is approaching though and we're in a feature-frozen, bugfix only mode, we'll do more frequent manual updates of the staging site.
我使用 Hudson 进行持续集成取得了巨大成功。 Redsolo 有关使用 Hudson 与 Python 的详细信息。
几个月前，有几篇文章支持持续部署在网上引起不小的轰动。 IMVU 详细介绍了它们每年最多部署 5 次日。
I've had great success using Hudson for continuous integration. Details on using Hudson with Python by Redsolo.
A few months ago, several articles espousing continuous deployment caused quite a stir online. IMVU has details on how they deploy up to 5 times a day.
您可以通过 Django 测试框架在夜间构建中轻松运行所有 Django 单元测试。
这就是我们所做的。
我们还有一些不利用 Django 功能的普通单元测试，我们也运行这些测试。
尽管 Python（和 Django）不需要编译语言那样的夜间编译/链接/单元测试，但您仍然受益于“不要破坏构建”的日常纪律。每天对你拥有的所有东西进行单元测试是一件好事。
我们正在努力研究 Python 2.6（它非常适合我们）并使用
-3选项运行我们的单元测试，以查看我们正在使用哪些已弃用的功能。拥有一整套单元测试可以确保 Python 3 兼容性的更改不会破坏构建。每晚运行它们意味着我们必须确保重构正确。You can easily run all of your Django unit tests through the Django testing framework as your nightly build.
That's what we do.
We also have some ordinary unit tests that don't leverage Django features, and we run those, also.
Even though Python (and Django) don't require the kind of nightly compile/link/unit test that compiled languages do, you still benefit from the daily discipline of "Don't Break The Build". And a daily cycle of unit testing everything you own is a good thing.
We're in the throes of looking at Python 2.6 (which works perfectly for us) and running our unit tests with the
-3option to see which deprecated features we're using. Having a full suite of unit tests assures us that a change for Python 3 compatibility won't break the build. And running them nightly means that we have to be sure we're refactoring correctly.如果您有正确的流程，持续集成就会很有用。如果您想熟悉 JetBrains 的 TeamCity，它是一个很好的起点：
http://www.jetbrains .com/teamcity/index.html
这里有一篇与 Django 直接相关的很棒的文章：
http://www.ajaxline.com/continuous-integration-in-django-project
希望这能让您开始。
Continuous integration is useful if you have the right processes around it. TeamCity from JetBrains is a great starting point if you want to build familiarity:
http://www.jetbrains.com/teamcity/index.html
There's a great article that relates directly to Django here:
http://www.ajaxline.com/continuous-integration-in-django-project
Hope this gets you started.