如何处理Web应用程序(SaaS)的发布管理?

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

他们在相当稳定的基础上推出新的版本(有时仅仅是个别的更改)(根据项目的不同,每天都如此)。但更关键的是:只有一小部分用户获得了新版本。

谷歌的大产品拥有大量的用户,因此,加入“5%的用户应该看到这个特性”这样的规则是可行的。

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

尽管工程师们想定义一个日常生活方式,但它实际上是由系统背后的业务需求驱动的。它还真的取决于更新的性质等…

内容和HTML更新不应该是一个大问题推出。应用程序的更改应该是一件大事,在被推送上线之前,要在预览站点上完成既定的测试程序。

有一点是肯定的,您需要有一个非常“干净”的方法来部署(和取消部署)更改。您还需要一种“简单”的方式来在变更生效之前对其进行审查和审计。

使用“git”和“rsync”的组合可以完全控制进程。对我们项目的所有更改都是在一个分支中进行的,该分支是从“生产”分支中分支出来的。在任何更改生效之前,“生产”分支必须完全合并。上线只是将适当的分支合并为“生产”并将其同步到活动服务器。Git让这很容易。

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

自从采用这个系统以来,我们的部署程序在效率和清晰度方面都有了显著的提高。顺便说一下,我们的部署范围从每天多次到每几个月一次。这要看情况而定。我希望在一个活跃的项目上每周发布1-2个版本。

尽早释放,通常是我做的,我们在工作的地方做的。我们也在博客上写下我们的更新。如果您一次将所有更新滚动到一个更新中(对于QA,必须回滚等),可能会更容易。从用户的角度来看,我认为很多更新没有任何问题。只要它们不是坏的更新。我认为如果你等了一整年或六个月,把所有的更新都放到一个大的版本中,就会有问题。这就扼杀了我以前从事的一个项目(一个你可能听说过的流行的饲料阅读器)。人们认为我们已经死了,感知变成了现实。我们被抛弃了。所以我完全赞成消防水带的发布计划。

每两周就够了,但这很大程度上取决于你们的市场。

在Planbox(基于Web的敏捷项目管理SaaS)中,我们每天都发布。我们可以这样做,因为我们的大多数应用程序逻辑,以及我们的所有表示逻辑都在前端(javascript)。甚至HTML也是通过使用模板引擎的JavaScript生成的。但是后端(PHP)及其RESTAPI很少改变。这使得我们可以随时推送新版本的客户端,而不会破坏兼容性。

如果你能转移到这样一个架构,你将节省大量的时间和获得更多的效率。