每天都在构建一个网络应用程序吗?

您可以在夜间构建时通过django测试框架轻松地运行所有django单元测试。

我们就是这么做的。

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

尽管python(和django)不需要像编译语言那样的夜间编译/链接/单元测试,但是您仍然可以从“不要破坏构建”的日常规则中获益。每天进行一次单元测试是件好事。

我们正痛苦地看着python 2.6(它非常适合我们)并用 -3 选项查看我们使用的已弃用的功能。拥有完整的单元测试套件可以确保更改python 3兼容性不会破坏构建。每晚运行它们意味着我们必须 当然 我们正在正确重构。

如果您周围有正确的流程,那么持续集成非常有用。如果您想建立熟悉度,JetBrains的TeamCity是一个很好的起点:

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

这里有一篇与Django直接相关的伟大文章:

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

希望这能让你开始。

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

这可能有助于阅读关于持续集成的主题,这是一个 非常 对webapp开发团队有用的实践。开发过程越快、越敏捷,就越需要来自自动化测试和质量度量的定期输入,以确保在任何损坏的代码版本上都能快速、大声地失败。

如果只是你和另一个开发人员在做,那么每晚的构建可能不会给你太多。

我会说,相当于夜间构建的Web应用程序将是临时站点(可以夜间构建)。

当你的客户、项目经理和质量保证人员需要能够看到最新但相对稳定的应用程序版本时,每晚建立到一个临时区域开始支付真正的红利。您的开发人员沙盒(如果您和我一样,至少)可能会花费大量时间处于不可用状态,因为您正在破坏一些东西,试图实现下一个特性。因此,典型的问题是,一个QA人员想要验证一个bug是否被修复,或者一个PM想要检查一些计划的特性是否被正确实现,或者一个客户想要看到您已经在他们关心的问题上取得了进展。如果他们只能访问开发人员的沙盒,那么很有可能当他们看到它时,沙盒版本没有运行(因为它意味着,/manage.py runserver在某个终端上)或者由于其他原因处于中断状态。这真的减慢了整个团队的速度,浪费了很多时间。

听起来您没有临时设置,因为您只是自动更新生产版本。如果你是 方式 比我(我认为大多数开发人员)更谨慎和有纪律,从不承诺任何不完全防弹的事情。就我个人而言,我宁愿确保我的工作在投入生产之前至少通过了一个非我的人的草率的质量保证。

因此,总之,我工作的设置:

• 每个开发人员都在本地运行自己的沙盒(与您一样)
• 在dev服务器上有一个“通用”的临时沙盒,每晚都会从cronjob中更新。PMS、客户和QA都会去那里。它们从未被授予直接访问开发人员沙盒的权限。
• 有一个自动的(虽然是手动启动的)生产部署。当我们觉得产品质量保证充分、稳定、安全时,开发人员或项目经理可以“推动”生产。

我想说唯一的缺点(除了设置夜间阶段构建的额外开销之外)是,它使一天的bug验证恢复正常。也就是说,QA报告软件中的一个bug(基于查看当天的夜间构建),开发人员修复bug并提交,然后QA必须等到第二天的构建检查bug是否已被修复。这通常不是什么大问题,因为每个人都有足够的事情进行,它不会影响日程安排。当一个里程碑即将到来,并且我们处于一个功能冻结、仅修正错误的模式时,我们将更频繁地手动更新登台站点。

我很成功地使用了 Hudson 用于持续集成。有关使用Hudson和python by的详细信息 Redsolo .

几个月前,几篇报道 continuous deployment 在网上引起了相当大的轰动。 IMVU 有关于他们如何 deploy up to 5 times a day .

频繁构建(像在持续集成中那样,每夜或更频繁地构建)背后的整个想法是获得即时反馈,以减少引入问题和检测问题之间的时间间隔。因此,只有当您能够通过编译(理想的自动化)测试、质量检查等生成一些反馈时,频繁构建才是有用的。没有反馈,就没有真正的意义。