WordPress 插件和主题开发人员的分阶段部署:避免“Clusterbug 发布”
已发表: 2020-12-23您还记得上次发布 WordPress 插件或主题的新版本以快速发现您错误地添加了一个新的主要错误,该错误会从您的测试序列裂缝中溜走吗?
Yoast SEO 3.0 早在 2015 年就打破了许多网站。Elementor 3.0 今年也做了同样的事情。 这些只是我在我们这个领域拥有 100 多名员工和专门的 QA 人员的出色公司中的两个例子(不,它与 3.0 版本无关,但也许这是在您的软件中跳过该版本的标志; ))。
无论您是自学成才的编码员或软件工程师、独立开发者,还是大型插件/主题商店的一员,我们都必须处理错误。 它是软件开发中不可避免的一部分。
无论您实施了何种花哨的 CI/CD/测试自动化——您将永远无法对其进行全部测试。 服务器配置的数量(PHP、MySql、缓存、Web 服务器)、WP 版本、插件和主题的组合……都是无穷无尽的。
这是违反直觉的。 您的产品越受欢迎和越稳定,发布可怕的“Clusterbug”的机会就越大,这会耗尽您的支持,可能会严重影响客户的信任和忠诚度,并可能损害整体品牌声誉。
虽然您无法避免错误,但您可以而且绝对应该尽可能地降低风险。
如果您有智能手机,您可能会注意到您的一些朋友会在您获得 Android/iOS 更新的几天、几周甚至几个月之前获得更新。 这不是巧合,不,这不是针对你个人的。 这是一个名为 Staged Rollouts 的有意渐进式部署过程,可帮助 Apple 等公司向超过 10 亿台设备提供主要软件更新。
是的,十亿!
如果必须同时向 15 亿台移动设备推送实时更新,您是否能理解 Apple 的版本负责人所肩负的责任? 我不能。 我敢打赌,没有一个理智的人会同意承担这样的责任。
那么,分阶段推出机制是如何工作的呢? 你怎么能实现它? WordPress.org 还在等什么? 这些是我将在下面介绍的主题。
什么是 WordPress 插件和主题的分阶段推出?
分阶段推出允许您指定要推出新版本的网站的数量(或百分比)。 分阶段推出机制使您能够以有限的曝光率开始您的发布周期,然后在您监控支持和反馈的同时逐步增加它,从而为您和您的用户建立对发布的信心。
分阶段推出的好处是什么?
您可以逐步发布版本,而不是冒着释放潜在错误、与第三方插件/主题冲突甚至 UI/UX 问题而冒着整个安装基础的风险,从而最大程度地减少暴露于意外问题的人员和网站的数量。 一旦您解决了在推出过程中发现的所有问题和错误,您的绝大多数用户将接触到一个“成熟”且更稳定的版本。
我们使用滚动更新来确保我们新版本的质量。 如果新版本出现问题,我们可以快速识别它,并且只有一小部分用户会受到影响。
SeedProd 创始人 John Turner
使用分阶段发布是负责任地发布软件的最佳实践——许多 WP 泡沫之外的公司(无论规模大小)都遵循这一过程。
WordPress 社区有很大的机会利用分阶段部署,我稍后会谈到。
Beta 计划是否类似于分阶段推出?
为您的 WordPress 产品设置一个 Beta 程序是一个很好的开始,但它远没有分阶段推出那么有效,而且它具有根本不同的目的和动态。
除非您的插件或主题非常受欢迎并且拥有庞大的社区,否则招募统计上足够的 beta 组是非常具有挑战性的,因为只有一小部分用户有兴趣加入。 即使你擅长招募一群像样的 beta 测试人员,你也必须依靠他们的可用性和善意来测试产品,然后希望他们付出额外的努力来报告他们发现的问题。
你觉得有多少人会看透这整个过程? 不太多。
Beta 测试是一个预生产过程,在此过程中您的支持工作受到完全控制,测试人员预计会遇到 Beta 版本的问题。 因此,测试人员对质量的期望并不代表您的用户群的普遍情绪。
此外,负责任的 Beta 程序会警告其测试人员避免在生产环境中使用 Beta 版本,因此 Beta 测试并不能真正模拟实时生产网站。
如何管理 WordPress 插件或主题的分阶段发布?
作为我对 Staged Rollouts 研究的一部分,我有机会与 Amir Helzer 进行电子会议,并从他们 2 年多的使用 Staged Rollouts 和 WPML 和 Toolset 的经验中学习,这些插件在超过 1,000,000 个 WordPress 网站上运行。
以下是 Amir 分享的关于他们的分阶段部署实施的内容:
当网站安装我们的任何插件时,我们会在 1 到 100 之间抽取一个随机数并将其存储在网站的数据库中以供记忆。 这种方法基本上以随机方式将网站分成 100 个箱。
当一个版本准备好上线时,它只会增量地可供单个选定的 bin 使用。 每天,我们都会在指定的 bin 中增加 5% 的网站在该版本的曝光率。 并在我们进行时修复和修补即将出现的问题。
为了使用更新版本使环境多样化并避免重复出现相同的早期版本“受害者”,Amir 确认每个新版本都会首先进入不同的用户群。
这种方法还意味着平均发布周期需要大约一个月才能为每个用户提供。
人们需要一段时间才能在 WP Admin 中看到可用的新版本并更新他们的版本。 即使在他们这样做之后,他们也可能需要几天的时间才能发现问题。
鉴于我们的受众规模,不可避免地,每个版本都会出现一些问题。 我们的主要目标是确保避免引入新问题,如果这样做,我们有一个可靠的流程来解决这些问题。
发布周期确实很长,但即使在最坏的情况下,我们在测试中遗漏了一些疯狂的错误,我们 95% 的用户甚至没有意识到所有的戏剧性,因为他们没有接触到发布直到稳定为止。
Amir 还强调了在发布之前与整个团队同步的重要性,尤其是客户支持和开发。 这样,团队成员可以额外关注因与正在进行的发布相关的问题而触发的工单,目的是检查、确认和修复有效问题并尽快发布补丁。
我们的团队中有三个支持层。 第 1 层将查看问题,通过重现它来验证它实际上是与插件发布相关的问题。 当一个案例似乎与新版本相关时,它会转到第 2 层,这将调试问题以验证它确实与版本相关,并在代码中找到触发问题的相关部分。 如果通过验证,负责该代码的开发人员将立即收到通知,以确定修复的优先级。
OnTheGoSystems 是一家拥有近 100 名员工的大公司,因此他们完善了分阶段推出流程是有道理的。 但是,即使作为拥有一个支持层(您和您自己)的单一产品开发人员,Amir 的洞察力也可以告诉我们,为发布分配专用资源至关重要。 最好优先考虑与您的新版本相关的甚至“闻起来”的支持票,并尽可能减少新问题的曝光。
为什么(几乎)没有支持分阶段推出的插件或主题?
在准备撰写本文时,我尝试询问社区谁在使用分阶段推出,以便获得有关他们的经验、他们学到的东西等方面的反馈。
不出所料,我发现我的网络中只有两家 WordPress 公司已将分阶段推出作为其发布周期的一部分。 许多开发人员甚至不知道这个概念,其余的人不使用它,因为他们的分发解决方案不支持它(或者他们可能已经考虑过开发它并且没有时间)。
大多数不通过 Freemius 销售的插件和主题开发人员通过 EDD 或 WooCommerce 从他们的网站销售,它们都不支持分阶段推出。 那些通过 CodeCanyon 和 ThemeForest 等市场销售的人也没有开箱即用的解决方案,而且很可能永远不会有。
即使是了解这个概念的开发人员也别无选择,只能开发自己的机制来支持分阶段推出。 这种基础设施开发通常很难在产品公司中优先考虑。
订阅并获取我们的免费副本
WordPress 插件商业书籍
究竟如何在订阅经济中创造繁荣的 WordPress 插件业务。
与朋友分享
输入您朋友的电子邮件地址。 我们只会通过电子邮件向他们发送这本书,童子军的荣幸。
谢谢你的分享
太棒了——“The WordPress Plugin Business Book”的副本刚刚发送到. 想帮助我们更多地传播信息吗? 继续,与您的朋友和同事分享这本书。
感谢订阅!
- 我们刚刚将您的“The WordPress Plugin Business Book”副本发送到.
您的电子邮件中有错字吗? 单击此处编辑电子邮件地址并再次发送。
分阶段部署如何为您带来商业优势?
由于目前几乎没有人利用分阶段推出,如果您开始使用分阶段推出并在您的网站上适当地推销它,让访问者知道您有负责任的发布周期,它肯定会给您带来竞争优势并增加对您产品的信任/品牌!
如果您从开发人员的角度分析市场,您会注意到许多开发人员密切关注他们的竞争对手,并且通常将他们的价格设置在垂直市场的价格范围内,这导致竞争的 WordPress 产品在相同的价格范围内提供类似的功能。
从买家的角度来看,这意味着购买哪种产品通常是一个折腾,因为它们都具有可比的功能和价格。 但是,当您评估几个成本相同且具有相同功能的插件时,您是否会倾向于使用提供分阶段推出的产品,因为它知道其生产版本应该比竞争对手更稳定?
分阶段推出可增强您对产品和业务的信心。 在分阶段推出成为标准做法之前,您可以利用这一优势(我真的希望他们这样做)。
Freemius 现在支持分阶段推出付费插件和主题
我们很高兴在高级 WordPress 插件和主题生态系统中率先推出分阶段部署。 我们的销售合作伙伴现在可以安全、自信、可靠地发布更新,而对他们的用户或支持/开发资源的影响最小。
我们知道主要版本有多么具有挑战性和令人伤脑筋,尤其是因为在“Clusterbug”版本发布后总是存在对您的品牌产生负面影响的潜在风险。
随着分阶段推出的到位,我们合作伙伴的品牌可持续性和可防御性有了一个安全网,并减轻了与向大量用户群发布相关的不必要的压力。
这为我们合作伙伴的客户带来了好处。 当用户购买通过 Freemius 销售的产品时,他们现在可以确信自己选择了由 Staged Rollouts 提供支持的解决方案,并且他们可以期待使用该机制的高级插件和主题发布更稳定的版本。
如果您使用 Freemius 进行销售,以下是正确使用我们的分阶段推出机制的方法。
Freemius 如何实施分阶段部署?
每个激活许可证以解锁高级插件或主题的网站都会在我们的数据库中记录。 我们所做的第一件事是引入一个新的last_served_update_version
属性来存储网站可用的最新产品版本。
然后,我们用两个新属性丰富了负责存储发布数据的表: limit
、 uniques
。
当开发人员将某个版本标记为已发布时,他们将收到以下对话框提示,允许他们设置具有活动许可证的网站的百分比(或数量),他们希望将付费版本推广到:
如果他们设置了有限发布发布,系统将计算具有有效许可证的活跃网站总数,然后相应地设置发布的新limit
属性。
最后,我们更新了网站调用的用于检查是否有新版本的 API 端点,并引入了以下逻辑(以伪代码形式):
latest_version = load latest version of product X If (website is on latest_version) return “no new version” If (last_served_update_version of website same as latest_version) return “no new version” If (latest_version is limited) If (latest_version is limited AND uniques >= limit) return “no new version” previous_version = load the previous version of product X If (previous_version is limited too AND uniques <= previous_version.uniques) If (website not using previous_version AND last_served_update_version different from previous_version) return “no new version” else If (random({true, false}) ) return “no new version” Set last_served_update_version of website to latest_version Increment uniques by 1 return latest_version
该算法确保:
- 发布的曝光根据设定的推出百分比进行限制。
- 如果之前的版本仍然是分阶段的,即它从未暴露给整个安装群,那么收到之前分阶段版本的网站将首先暴露给最新的分阶段版本。
与 WPML 的分阶段推出架构不同,该架构确保每个版本都将使用逻辑箱进入其安装库的不同子集,我们的实现依赖于随机性。 因此,一个网站可能会在两个连续的发布周期中获得两个早期版本。 但是,这种方法的好处是我们能够向所有合作伙伴的客户提供分阶段部署,而无需推送 SDK 更新,这可能需要数月甚至数年才能传播给所有客户。
为什么分阶段部署对于 WordPress 的未来至关重要?
当我问阿米尔他们为 WPML 发布周期开发分阶段部署的触发因素是什么时,这是他告诉我的:
3 年前,在 WordCamp Europe,我花时间与 WPML 客户聊天,收集有关他们整体体验的各种反馈。 我发现的第一大挫折是我们的客户害怕更新插件,因为它可能会意外破坏他们的网站。
阿米尔·赫尔泽,
OnTheGoSystems(WPML,工具集)创始人
我绝对与此有关。
在更新插件和主题方面,我们在 Freemius 的内部政策是……根本不这样做! 有两个例外:如果存在已知的安全问题或我们网站需要的较新版本中可用的功能。
我们的更新政策是“血写的”,因为发生了几次错误的更新事件并导致了意想不到的头痛和时间浪费,从而中断了我们的运营和时间表。 是的,我们本可以通过暂存环境避免一些压力,但是如果我们仍然想继续更新到生产环境,这不会为我们节省时间和麻烦。
从那时起,WordPress 有了一些发展,现在我们可以在插件失败时自动停用。 但是,这不适用于主题,停用我们网站的关键任务插件仍然是一个大问题。
底线是,如果我作为插件开发人员和一家帮助成千上万的插件和主题开发人员发展业务的公司的首席执行官,我担心每次我们更新网站上的插件或主题时都会破坏我们的网站,那么这当然意味着大多数用户对更新我们空间中的软件没有信心。
缺乏分阶段推出让我们和整个 WP 生态系统倒退,并为基于 SaaS 的竞争解决方案提供了相当大的优势。 WiX 和 Shopify 用户根本不需要考虑更新! 更新只是在后台为他们进行,他们的软件始终是最新的、安全的和功能方面的。
缺乏分阶段推出阻碍了整个 WP 生态系统,并为基于 SaaS 的解决方案提供了相当大的优势。 WiX 和 Shopify 用户不需要考虑软件更新——它们只是在后台发生。Tweet
如果您观看了上周的 State of the Word,WordPress 联合创始人 Matt Mullenweg 显然明白了最新软件的重要性。 这是马特对 WP 更新的愿景:
… 允许您选择加入 Core 的自动更新。 这是我们实现目标的第一步,让您的 WordPress 基本上可以自我维护,当您可以设置它并忘记它时,它将在后台自动进行,并且对您的所有插件、主题和核心进行无忧更新。
我可以想象 WordPress 成为“一劳永逸”的唯一方法是软件更新是否可以更加可靠和可信,而这只能通过分阶段推出来实现。
WordPress.org:这是为插件和主题存储库引入分阶段部署的方法
与我们的实现类似,WordPress.org 数据库中的每个插件和主题版本都需要添加两个新的元选项: limit
和uniques
。
可以在高级视图中为登录的所有者(也可能为其他提交者)公开limit
元选项编辑:
开发人员将有办法控制每个版本的曝光,以及为下一个版本设置限制的能力。
由于 WordPress.org 不会为每个从 WordPress.org 接收更新的网站存储结构化数据,而不是将网站“看到”的最新版本存储在 WordPress.org 数据库中,数据的存储可以委托给网站. 这意味着'update_plugins'
瞬态和在检查更新时发送到 WordPress.org API 的数据将需要使用last_served_update_version
进行丰富。
最后,WordPress.org 更新 API 端点可以使用我们用于 Freemius 分阶段部署实施的相同逻辑来丰富。 该机制不依赖于 wp.org 数据库中的last_served_update_version
,而是依赖于核心从网站发送的值。
轻轻松松,不是吗?
让我们恢复用户点击更新按钮的信心
我们都希望看到 WordPress 成功并不断发展壮大和更好!
有这么多资源进入古腾堡,很明显 WordPress 的领导层承认我们必须让普通的非技术人员更容易访问该平台。 问题是,只要软件更新不可信,即使有古腾堡和我们可用的所有令人惊叹的页面构建器,一个非技术人员也会在他们第一次失败的更新时跑到 Wix,我不能责怪他们。
我向 EDD 的创始人 Pippin Williamson、WooCommerce 首席执行官 Paul Maiorana 和 WordPress.org 团队呼吁:我们有机会为更大的 WordPress 社区打造更加稳定的插件和主题生态系统。 让我们让用户能够以更少的恐惧和挫败感来保持他们的软件安全和最新。 虽然它在短期内可能看起来不是一个高优先级,但我相信从长远来看,我们都会从中受益。