您如何进行 Web 应用程序 (SaaS) 的发布管理？
发布托管 Web 应用程序新版本的最佳方法是什么？通常发布的频率是多少？ 您是否选择任意日期（例如每周、每月等）来推出一组累积的修复程序（可能使用类似于 乔尔对发货日期的处理方式）？ 等待比这更长的时间似乎削弱了托管应用程序的部分主要优势。 另一方面，您不想不断推出可能使用户感到困惑的新功能（即，如果他/她每次登录时都有不同的东西）。
直到最近，我的经验主要是安装基于服务器或桌面的应用程序。 我很好奇人们在托管应用程序中使用什么类型的发布管理。
What is the best approach to releasing a new version of a hosted web app, and how often do you typically release? Do you pick an arbitrary date, say every week, month, etc. to rollout an accumulated set of fixes (perhaps using an approach similar to Joel's approach to ship dates)? Waiting much longer than that seems to defeat part of the major advantage of a hosted app. On the other hand, you wouldn't want to constantly roll out new features that might confuse the user (i.e., if there was something different every time he/she logged in).
Until recently my experience has been primarily with installed server-based or desktop apps. I am curious to see what type of release management people use with a hosted app.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
谷歌的方法可能对最终用户来说是最好的，但它是以复杂性为代价的。
他们经常（每天一次，具体取决于项目）推出新版本（有时只是个别更改）。 但问题在于：只有一小部分用户获得了新版本。
谷歌的大产品拥有大量用户，因此制定“5％的用户应该看到此功能”之类的规则是很实用的。
然后，他们可以分析结果并计划下一个版本，可能面向另外 15% 的用户群。
Google's approach is probably the best for the end user, but it comes at the cost of complexity.
They roll out new versions (and sometimes just individual changes) on a pretty constant basis (as often as daily, depending on the project). But here's the kicker: only a small portion of users are given the new version.
Google have a large number of users for their big products, so it's practical to put in rules like "5% of users should see this feature".
They can then analyse the results and plan their next release, perhaps to another 15% of the user population.
尽管工程师希望定义一个日常工作，但它实际上是由系统背后的业务需求驱动的。 它还实际上取决于更新的性质等...
内容和 HTML 更新不应该是一个大问题。 应用程序更改应该是一件大事，并在发布之前在预览网站上完成既定的测试例程。
可以肯定的一件事是，您需要一种非常“干净”的方式来部署（和取消部署）更改。 您还需要一种“简单”的方法来在更改生效之前对其进行审查和审核。
混合使用“git”和“rsync”可以让我们完全控制该过程。 我们项目的所有更改都是在“生产”分支的分支中开发的。 在任何更改上线之前，必须完全合并“生产”分支。上线的行为只是将适当的分支合并到“生产”中并将其同步到实时服务器。 Git 让这一切变得非常简单。
这确保了正在实施的变更不可能与正在进行的其他变更发生冲突。
自从采用该系统以来，我们的部署例程的效率和清晰度显着提高。 顺便说一下，我们的部署范围从每天多次到每几个月一次。 这一切都取决于。 我更喜欢在活跃项目上每周发布 1-2 个版本。
As much as engineers want to define a routine to live by, it is really going to be driven by the business demands behind the system. It also really depends on the nature of the updates, etc...
Content and HTML updates should not be a big deal to push out. Application changes SHOULD be a big deal, and go through the established testing routines on a preview site prior to being pushed live.
One thing for sure is that you need to have a very "clean" way to deploy (and undeploy) changes. You also need an "easy" way to review and audit the changes before they go live.
Using a mix of "git" and "rsync" allows us total control over the process. All changes to our project are developed in a branch that was branched from the "Production" branch. Before any changes can go live, the "Production" branch must be fully merged in. The act of going live is simply merging the appropriate branch into "Production" and rsyncing it to the live servers. Git makes this really easy.
This ensures that the changes going live cannot possibly conflict with other changes in progress.
Since adopting this system, our deployment routine has dramatically increased in efficiency and clarity. And by the way, our deployments range from multiple times per day to once every several months. It all depends. I would prefer a 1-2 release per week cycle on an active project.
尽早并经常发布是我所做的，也是我们在工作中所做的。 每当我们进行更新时，我们也会在博客上发布更新。 如果您尽可能将所有更新一次滚动到一个更新中（用于 QA、必须回滚等），这对您来说可能会更容易。 从用户的角度来看，我认为大量更新没有任何问题。 只要它们不是糟糕的更新。 我认为如果你等待一整年或六个月，然后将所有更新整合到一个大版本中，就会出现问题。 这就是我曾经参与的一个项目（你可能听说过的一个流行的提要阅读器）的原因。 人们以为我们已经死了，而感知变成了现实。 我们被抛弃了。 所以我完全赞成消防水带发布时间表。
Release early and often is what I do, and what we do where we work. We also blog about our updates whenever we make them. It's probably easier for you if you roll all your updates into one update at a time (for QA, having to rollback, etc) as best as you can. From a user perspective I don't think there's any problem with lots of updates. As long as they're not bad updates. I think there is a problem if you wait for an entire year or six months, and roll all your updates into one big release. That's what killed a project I used to work on (a popular feedreader you've probably heard of). People thought we were dead, and perception became reality. We got abandoned. So I'm all for firehose release schedules.
每两周就足够了，但这很大程度上取决于您的市场。
Every two weeks should be enough, but this depends very much on your market.
在 Planbox（基于网络的敏捷项目管理 SaaS），我们每天都会发布。 我们可以这样做，因为我们的大部分应用程序逻辑和所有表示逻辑都位于前端（Javascript）。 甚至 HTML 也是使用模板引擎通过 Javascript 生成的。 但后端（PHP）及其 REST API 很少改变。 这使我们能够随时推送新版本的客户端，而不会破坏兼容性。
如果您可以迁移到这样的架构，您将节省大量时间并提高效率。
At Planbox (web-based Agile project management SaaS) we release every day. We can do that because most of our application logic, and all of our presentation logic are in the front-end (Javascript). Even the HTML is generated via Javascript using a templating engine. But the backend (PHP) and its REST API rarely change. This allows us to push new versions of the client any time without breaking compatibility.
If you can move to such an architecture, you'll save tons of time and gain much efficiency.