每日构建是否适合 Web 应用程序？答案

【问题标题】：Are daily builds the way to go for a web app?每日构建是否适合 Web 应用程序？
【发布时间】：2009-09-17 22:50:04
【问题描述】：

Joel 似乎是think highly of daily builds。对于传统的编译应用程序，我当然可以看到他的理由，但是这与 Web 开发有何相似之处——或者不是？

关于我要求的项目的一些信息—— 有 2 名开发人员正在开发 Django (Python) Web 应用程序。我们有 1 个 svn 存储库。每个开发人员维护自己的本地运行 MySQL 的结帐和副本（如果您不熟悉 Django，它与自己的测试服务器捆绑在一起，很像 ASP 应用程序可以在 Visual Studio 中运行的方式）。开发和测试在本地完成，然后提交回存储库。该网站的实际工作副本是一个 SVN 结帐（我知道 SVN 导出，它需要很长时间）。我们最接近“构建”的是一个批处理文件，它在工作副本上运行 SVN 更新，执行 django 位（“manage.py syncdb”），更新搜索引擎缓存（solr），然后重新启动 apache。

我想我没有看到与网络应用程序类似的地方。

您是否正在使用“夜间构建”来开发受源代码控制的 Web 应用程序 - 如果是，那是什么样的？

【问题讨论】：

标签： django unit-testing version-control nightly-build

【解决方案1】：

您可以通过 Django 测试框架轻松运行所有 Django 单元测试，作为您的夜间构建。

这就是我们所做的。

我们还有一些不利用 Django 功能的普通单元测试，我们也会运行这些测试。

即使 Python（和 Django）不需要编译语言那样的夜间编译/链接/单元测试，您仍然可以从“不要破坏构建”的日常纪律中受益。每天对你拥有的一切进行单元测试是一件好事。

我们正在苦苦研究 Python 2.6（它非常适合我们）并使用 -3 选项运行我们的单元测试，以查看我们正在使用哪些已弃用的功能。拥有一整套单元测试可以确保我们对 Python 3 兼容性的更改不会破坏构建。每晚运行它们意味着我们必须确定我们正在正确地重构。

【讨论】：

+1 动态语言的 Web 应用程序通常根本不需要“构建”，但强烈建议进行持续集成测试。

【解决方案2】：

如果您有正确的流程，持续集成会很有用。如果您想建立熟悉度，JetBrains 的 TeamCity 是一个很好的起点：

http://www.jetbrains.com/teamcity/index.html

这里有一篇与 Django 直接相关的好文章：

http://www.ajaxline.com/continuous-integration-in-django-project

希望这能让你开始。

【讨论】：

【解决方案3】：

以动态语言构建的 Web 应用程序可能不需要“编译”步骤，但在使应用程序运行时仍可能涉及许多“构建”步骤。您的构建脚本可能会安装或升级依赖项，执行数据库迁移，然后运行测试套件以确保代码是“干净的”w.r.t。存储库中的实际签入版本。或者，您可以将代码副本部署到测试服务器，然后针对新版本运行一组 Selenium 集成测试，以确保核心站点功能仍然有效。

阅读持续集成这一主题可能会有所帮助，这对于 webapp 开发团队来说是一个非常有用的做法。您的开发过程越快节奏和敏捷，您就越需要定期输入来自自动化测试和质量指标的信息，以确保您在任何损坏的代码版本上快速而响亮地失败。

【讨论】：

+1 是我看到的第一个答案，它将构建过程的非编译方面的想法与持续集成的建议相结合。 FWIW，我很幸运使用 CruiseControl 作为 web 应用程序。

【解决方案4】：

如果真的只有您和其他开发人员在开发它，那么夜间构建可能不会给您带来太多好处。

我会说，相当于每晚构建的网络应用程序将是登台站点（可以每晚构建）。

当您的客户、项目经理和 QA 人员需要能够查看最新但相对稳定的应用版本时，才能开始为临时区域的夜间构建带来真正的好处。您的开发人员沙箱（至少如果您像我一样）可能会花费大量时间处于不可用状态，因为您正在尝试实现下一个功能。因此，典型的问题是 QA 人员想要验证 bug 是否已修复，或者 PM 想要检查某些计划中的功能是否正确实施，或者客户想要看到您在他们关心的问题上取得了进展关于。如果他们只能访问开发人员沙箱，那么当他们开始查看沙箱时，很有可能沙箱版本没有运行（因为这意味着 ./manage.py runserver 在某处的终端中启动）或者它正在运行由于其他原因处于破碎状态。这确实会减慢整个团队的速度并浪费大量时间。

听起来您没有暂存设置，因为您只是自动更新生产版本。如果您方式比我（我认为大多数开发人员）更加谨慎和自律，并且从不提交任何不完全防弹的事情，那可能会很好。就个人而言，我宁愿确保我的作品在投入生产之前至少通过了除我之外的其他人的一些粗略的 QA。

所以，总而言之，我工作的设置：

每个开发人员都在本地运行自己的沙箱（与您一样）
开发服务器上有一个“通用”暂存沙箱，每晚从 cronjob 更新。 PM、客户和 QA 都去那里。他们永远无法直接访问开发者沙箱。
有一个自动化的（虽然是手动启动的）部署到生产环境。当我们觉得事情已经得到充分的 QA 并且稳定和安全时，开发人员或 PM 可以“推动”生产。

我想说唯一的缺点（除了设置每晚临时构建的一些额外开销之外）是它需要一天的错误验证周转时间。即，QA 报告软件中的错误（基于查看当天的夜间构建），开发人员修复错误并提交，然后 QA 必须等到第二天的构建来检查错误是否已真正修复。这通常不是什么大问题，因为每个人都有足够的事情在做，不会影响日程安排。但是，当一个里程碑即将到来并且我们处于功能冻结、仅修复错误的模式时，我们将更频繁地手动更新暂存站点。

【讨论】：

【解决方案5】：

我在使用Hudson 进行持续集成方面取得了巨大成功。 Redsolo 使用 Hudson 和 Python 的详细信息。

几个月前，几篇支持continuous deployment的文章在网上引起了不小的轰动。 IMVU 有他们如何deploy up to 5 times a day 的详细信息。

【讨论】：

【解决方案6】：

频繁构建（夜间构建或更频繁，如持续集成）背后的整个想法是获得即时反馈，以减少从引入问题到检测到问题所经过的时间。因此，只有当您能够通过编译、（理想情况下是自动化的）测试、质量检查等产生一些反馈时，频繁构建才有用。没有反馈，就没有实际意义。

【讨论】：