应用程序版本和升级概述¶

关于应用程序版本和补丁¶

Snowflake Native App Framework 允许提供商创建应用程序的版本和补丁。版本和补丁允许供应商向消费者发布新功能和更新。

版本

通常包含对 Snowflake Native App 的重大更新。版本通常会为应用程序推出新功能和更改功能。

补丁

通常包含对 Snowflake Native App 的较小更新。与版本不同，补丁只应包含小的更新，如安全修复。

应用程序的版本和补丁在应用程序包中指定。

要为当前已定义两个版本的应用程序包添加新版本，提供商必须删除其中一个现有版本。要删除版本，提供商必须执行以下操作：

1. 确保所有用户都已从要删除的版本升级。

2. 从应用程序包中删除版本。

3. 创建新版本。

4. 升级应用程序。

尽管应用程序包一次只能包含两个活动版本，但单个版本可以有多个补丁。Snowflake Native App Framework 不支持删除补丁。当提供商为应用程序包添加新版本时，默认情况下会自动为新版本分配补丁 0。这无法更改。

当提供商将新补丁添加到版本时，他们可以手动指定补丁的标识符。如果未提供补丁号，Snowflake 会自动将补丁版本递增 1。

有状态对象和无状态对象¶

在开发应用程序的新版本时，提供商必须考虑所修改的组件是否需要从一个版本或补丁保留到另一个版本或补丁的状态。典型的应用程序包含两类组件：

无状态对象

应用程序的每个新版本或补丁都会重新创建无状态对象。无状态对象只需在版本生命周期内可用，必要时可重新创建。无状态对象通常是应用程序的代码，包括存储过程、用户定义的函数、Streamlit 应用程序和类似内容。

无状态对象应在 版本化架构 中创建。

有状态对象

有状态对象可从应用程序的一个版本或补丁共享到另一个版本或补丁。有状态组件的目标是在应用程序的多个版本中都能持续使用。例如，如果应用程序使用一个表来存储使用者账户中的配置信息，那么在升级过程中就需要保留该表的内容。

有状态对象应使用常规架构创建。

关于版本化架构¶

在为新版应用程序编写安装脚本时，提供商必须考虑到无状态组件和有状态组件。为了处理无状态对象，Snowflake Native App Framework 提供了一种特殊类型的数据库架构，称为版本化架构。版本化架构与常规数据库架构类似，但增加了处理不同应用程序版本创建的多个版本对象的功能。

有关更多信息，请参阅 使用版本化架构跨版本管理应用程序对象。

关于应用程序升级¶

Snowflake Native App Framework 允许提供商将应用程序升级到新版本或补丁。要了解升级如何融入开发应用程序新版本或补丁的整体工作流程，请参阅 更新应用程序的工作流程。

提供商可以通过在应用程序包上设置发布指令，将应用程序升级到新版本或补丁。修改发布指令后，Snowflake 会自动将当前版本应用程序的所有已安装实例升级到发布指令指定的版本。

当提供商启动升级时，Snowflake 会将每个要升级的应用程序添加到队列中。每个应用程序都会根据可用资源进行升级。在所有已安装的应用程序版本中，升级过程可能需要一段时间才能完成。为了加快升级过程，使用者还可以在有新版本或补丁时手动启动应用程序升级。

有关更多信息，请参阅 升级应用程序。

应用程序版本和补丁的生命周期¶

要了解应用程序版本和补丁如何协同工作，请考虑这样一种情况：提供商发布了应用程序的初始版本 v1，使用者 A 和使用者 B 在其账户中安装了该版本的应用程序。

下面几节将介绍这种情况。

版本 v1.0 已安装在用户账户中¶

图 1 显示了提供商发布的应用程序版本 v1.0，两个使用者在自己的账户中安装了该应用程序：

该图显示如下内容：

• v1.0 的应用文件存储在一个暂存区中。

• 应用程序包的发布指令设置为 v1.0。

• 使用者在其账户中安装了 v1.0。

• 提供商已开始在其账户中开发版本 v2.0。

在应用程序包中添加版本 v2.0¶

图 2 显示提供商已上传了版本 v2.0，并在应用程序包中创建了一个新版本：

该图显示如下内容：

• 在本地测试完应用程序的版本 v2.0 后，提供商将 v2.0 文件上传到暂存区

• 提供商为应用程序包中的应用程序创建一个新版本。

• 发布指令继续指向应用程序的版本 v1.0。

• 使用者继续在其账户中安装版本 v1.0。

将应用程序从版本 v1.0 升级到版本 v2.0¶

要将应用程序从版本 v1.0 升级到版本 v2.0，提供商会将应用程序包的 发布指令 设置为版本 v2.0。这将启动使用者账户中应用程序的升级过程。

升级完成后，使用者 A 和 B 的账户中都安装了版本 v2.0，如 图 3 的图表所示。

此外，在这种情况下，提供商已开始在本地开发环境中开发和测试版本 v3.0。

删除版本 v1.0，以便创建 v3.0¶

测试完成后，提供商将版本 v3.0 上传到暂存区。当提供商要开始升级到版本 v3.0 时，必须首先确保所有用户都已从版本 v1.0 迁移。

在上一节所示的情景中，所有使用者目前都使用 v2.0。

如 图 4 所示，提供商必须从应用程序包中删除版本 v1.0：

在应用程序包中添加版本 v3.0¶

删除版本 v1.0 后，提供商可以在应用程序包中添加版本 v3.0。在这种情况下，发布指令仍指向 v2.0，使用者的账户中已安装了 v2.0。

升级到版本 v3.0¶

要升级到 v3.0，提供商将更新发布指令，以指向 v3.0。这将开始升级。升级完成后，使用者将升级到版本 v3.0，如下图所示：