您如何处理Web应用程序（SaaS）的发布管理？

Question

发布新版托管网络应用的最佳方法是什么，以及您通常发布的频率是多少？您是否选择任意日期，例如每周，每月等，以推出一组累积修复（可能使用类似于Joel's approach to ship dates的方法）？等待的时间比这要长得多，似乎打败了托管应用程序的部分主要优势。另一方面，您不希望不断推出可能使用户感到困惑的新功能（即，每次他/她登录时是否存在不同的内容）。

直到最近，我的经验主要是安装基于服务器或桌面的应用程序。我很想知道人们使用托管应用程序的版本管理类型。

Answer 1

谷歌的方法对最终用户来说可能是最好的，但它的代价是复杂性。

他们在相当不变的基础上推出了新版本（有时只是个别更改）（根据项目的不同，每天都会这样）。但这里是踢球者：只有一小部分用户获得了新版本。

Google为其大型产品提供了大量用户，因此制定“5％的用户应该看到此功能”等规则是切合实际的。

然后他们可以分析结果并计划他们的下一个版本，可能是另外15％的用户群。

Answer 2

尽管工程师想要定义一个生活的例程，但它确实会受到系统背后的业务需求的驱动。它还真的取决于更新的性质等......

内容和HTML更新不应该是一个很大的推动。应用程序更改应该是一个大问题，并在推送之前在预览网站上完成已建立的测试例程。

有一点可以肯定的是，您需要采用非常“干净”的方式来部署（和取消部署）更改。您还需要一种“简单”的方式来检查和审核更改，然后再将其发布。

使用“git”和“rsync”的混合使我们可以完全控制该过程。对我们项目的所有更改都是在从“生产”分支分支的分支机构中开发的。在任何更改生效之前，“生产”分支必须完全合并。上线行为只是将适当的分支合并到“生产”并将其发送到实时服务器。 Git让这很容易。

这可确保更改生效不会与正在进行的其他更改发生冲突。

自采用该系统以来，我们的部署程序在效率和清晰度方面都有了显着提高。顺便说一句，我们的部署范围从每天多次到每几个月一次。这完全取决于。我希望在一个活跃的项目中每周发布1-2个周期。

Answer 3

提前发布，经常是我的工作，以及我们在哪里工作。每当我们制作更新时，我们也会发布有关我们更新如果您将所有更新一次性转换为一个更新（对于QA，必须回滚等），那么对您来说可能更容易。从用户的角度来看，我认为大量更新没有任何问题。只要他们不坏更新。我认为如果您等待整整一年或六个月会出现问题，并将所有更新推送到一个大版本中。这就是杀死我曾经工作的项目（你可能听说过的一种流行的feedreader）。人们认为我们已经死了，感知变成了现实。我们被遗弃了。所以我都是为了消防发布时间表。

Answer 4

每两周应该足够了，但这在很大程度上取决于您的市场。

Answer 5

在Planbox（基于网络的敏捷项目管理SaaS），我们每天都会发布。我们可以这样做，因为我们的大部分应用程序逻辑和所有的表示逻辑都在前端（Javascript）。甚至HTML也是使用模板引擎通过Javascript生成的。但后端（PHP）及其REST API很少改变。这使我们可以随时推送新版本的客户端而不会破坏兼容性。

如果你可以转向这样的架构，你将节省大量的时间并获得更高的效率。