9

Joel似乎很重视日常构建。对于传统的编译应用程序，我当然可以看到他的理由，但是这与 Web 开发有何相似之处——或者不是吗？

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

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

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

4

6 回答 6

11

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

这就是我们所做的。

我们也有一些不利用 Django 特性的普通单元测试，我们也运行这些单元测试。

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

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

于 2009-09-17T22:56:32.523 回答
3

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

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

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

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

希望这能让你开始。

于 2009-09-17T22:54:12.113 回答
3

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

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

于 2009-09-17T22:55:49.780 回答
2

如果真的只有你和另一位开发人员在做这件事，那么夜间构建可能不会给你带来太多好处。

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

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

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

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

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

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

于 2009-09-18T15:18:36.213 回答
1

我在使用Hudson进行持续集成方面取得了巨大成功。Redsolo的有关将 Hudson 与 Python结合使用的详细信息。

几个月前，几篇支持持续部署的文章在网上引起了不小的轰动。 IMVU详细介绍了他们如何每天部署多达 5 次。

于 2009-09-17T23:14:40.163 回答
1

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

于 2009-09-17T23:46:24.657 回答