发布托管网络应用的新版本的最佳方法是什么？您通常多久发布一次？您是否选择任意日期，例如每周、每月等来推出一组累积的修复（可能使用类似于Joel's approach to ship dates 的方法）？等待比这更长的时间似乎破坏了托管应用程序的部分主要优势。另一方面，您不希望不断推出可能使用户感到困惑的新功能（即，如果他/她每次登录时都有不同的东西）。
直到最近，我的经验主要是安装基于服务器或桌面应用程序。我很想知道人们对托管应用使用什么类型的发布管理。
【问题讨论】：
标签： web-applications release release-management
在 Planbox（基于 Web 的敏捷项目管理 SaaS），我们每天都会发布。我们可以这样做，因为我们的大部分应用程序逻辑和我们所有的表示逻辑都在前端（Javascript）中。甚至 HTML 也是使用模板引擎通过 Javascript 生成的。但后端 (PHP) 及其 REST API 很少更改。这让我们可以在不破坏兼容性的情况下随时推送新版本的客户端。
如果您可以迁移到这样的架构，您将节省大量时间并提高效率。
【讨论】：
尽管工程师想要定义一个日常工作，但它实际上是由系统背后的业务需求驱动的。这也确实取决于更新的性质等...
内容和 HTML 更新应该不是什么大问题。应用程序更改应该是一件大事，并在发布之前在预览网站上完成既定的测试程序。
可以肯定的是，您需要有一种非常“干净”的方式来部署（和取消部署）更改。您还需要一种“简单”的方式来在更改上线之前对其进行审核和审核。
混合使用“git”和“rsync”可以让我们完全控制整个过程。我们项目的所有更改都是在从“生产”分支分支出来的分支中开发的。在任何更改上线之前，必须完全合并“生产”分支。上线的行为只是将适当的分支合并到“生产”中并将其同步到实时服务器。 Git 让这一切变得非常简单。
这可确保生效的更改不会与正在进行的其他更改发生冲突。
自从采用该系统后，我们的部署例程在效率和清晰度上都有了显着提高。顺便说一句，我们的部署范围从每天多次到每几个月一次。这一切都取决于。我希望在一个活跃项目上每周发布 1-2 个版本。
【讨论】：
Google 的方法可能是最适合最终用户的方法，但其代价是复杂性。
他们非常稳定地推出新版本（有时只是个别更改）（根据项目，每天一样频繁）。但关键在于：只有一小部分用户获得了新版本。
Google 的大型产品拥有大量用户，因此制定“5% 的用户应该看到此功能”之类的规则很实用。
然后，他们可以分析结果并计划下一个版本，可能面向另外 15% 的用户群。
【讨论】：
每两周应该足够了，但这在很大程度上取决于您的市场。
【讨论】：
尽早发布并经常发布是我的工作，也是我们在工作地点所做的工作。每当我们进行更新时，我们也会在博客中介绍我们的更新。如果您一次尽可能地将所有更新滚动到一个更新中（对于 QA、必须回滚等），您可能会更容易。从用户的角度来看，我认为大量更新没有任何问题。只要它们不是糟糕的更新。我认为如果您等待一整年或六个月，然后将所有更新整合到一个大版本中，就会出现问题。这就是我曾经从事的一个项目（你可能听说过的流行的 feedreader）的原因。人们认为我们已经死了，感知变成了现实。我们被遗弃了。所以我完全赞成消防水管的发布时间表。
【讨论】：