应用升级(3)发布升级

学习目标

完成本单元后,您将能够:

  • 解释Salesforce如何帮助您在不中断客户的情况下提供更新。
  • 列出可以向客户提供升级的不同方式。
  • 描述可用于使客户更容易升级的工具。

最新版本,请!

在最后一个单元中,您了解了软件包版本号,该软件包标识了托管软件包的唯一版本。

相同包的不同版本可以是不同的。应用程序中的主要版本更改可能会大幅改变其行为。即使是轻微的版本更改也可以在后面修改几件事情。软件包版本号帮助您通过强制您考虑更改对他们的影响来保护您的客户免受破坏性更改。

正如我们所提到的,维护您的产品的不同版本并不理想。尽量让您的所有客户都保留在您的产品的单一版本(最新版本)上。这为每个人提供了相同的体验,最新的错误修复以及所有最酷的功能。

让我们看看如何完成。

推动升级给你的客户

如果您真的希望您的客户使用您的产品的最新版本,有一个简单的方法可以确保他们:使用推送升级。在推送升级中,您可以将最新版本的产品推送给客户。他们不需要做任何事情来完成升级 – 他们只要使用新版本就可以完成升级。

您可以对升级(主要或次要)和补丁使用推送升级。推送升级完成后,客户会在其产品的“包装详细信息”页面上看到新的版本号。当然,他们也会看到你所有的酷炫新功能。

沟通,沟通,沟通

我们希望到现在为止,我们已推销推送升级。现在您可以将这个词传递给您的客户 – 他们当然希望在获得它之前了解即将推出的推送升级!

在升级中,与大多数活动一样,通信至关重要。有关管理预期和最小化影响的一整套指导方针,请查阅ISVforce指南。

如何成为推手

以下是推送升级的工作原理:

  • 您选择一个或多个客户组织进行升级。
  • 您选择要在这些组织上安装的产品版本。
  • 您计划给定日期和时间的升级。
  • 您可以跟踪升级的进度。检查它是否成功完成,或者如果要重新计划,请中止待定的升级。

这是高层次的观点。您可以决定升级如何工作 – 哪些组织会先更新,以及每个组织会发生什么情况。

拥有权利的同时也被赋予了重大的责任

推送升级可以让您控制。您可以分发任何内容,从简单的修补程序到对产品进行大修。您可以升级单个客户或全部客户。

正确完成,推送升级可以无缝 – 每个人都可以获得新版本并使用它。做得不好,呃……每个使用电脑的人都知道一个拙劣的升级是什么样的。

使用你的判断。如果您添加了许多功能或组件,请考虑影响:

  • 这些组件是否适用于现有的安装?
  • 您的升级是否会影响常见的定制?
  • 您的升级是否以破坏性的方式修改客户数据?

新功能易于管理 – 您的客户在升级之前不会使用它们。现有的功能更棘手。尝试保持事物的运作方式,让您的客户保持高效。

AppExchange合作伙伴需要特殊权限才能推送升级。在Salesforce合作伙伴社区中记录案例以请求推送主要升级和修补程序权限。

大国不是绝对权力

推送升级有其局限性:

  • 升级的权限集不包含选项卡可见性设置。
  • 安装后无法自动激活远程站点设置。

当您计划部署时,请牢记这些 – 您必须与客户协调这些类型的升级。

自动化细节

升级比全新安装更复杂,因为它们会对现有系统进行更改。谁知道客户组织中发生了什么?

有时您需要在安装后执行安装后的工作任务。例如,您可以修改客户数据以适应更新的公式或解决不一致问题。使用我们新的Apex元数据API,您可以在向包中添加新的自定义字段时更新页面布局。

Salesforce允许您为安装后工作编写一个Apex类。在升级安装到组织中后,此类将执行其工作。

这样的班级是什么样的?这里有一个简单的例子:

    global class PostInstallClass implements InstallHandler {
      global void onInstall(InstallContext context) {
        if(context.previousVersion() == null) {
          //这意味着该软件包是第一次安装
          // 执行首次安装所需的活动
          Account a = new Account(name='NewAccount');
          insert(a);      
        }
        else if(context.previousVersion().compareTo(new Version(1,0)) == 0) {
          // 这意味着以前的版本是1.0 
        }
        if(context.isUpgrade()) {
          // 这意味着软件包正在升级
          // 执行包升级所需的活动
        }
        if(context.isPush()) {
          //这意味着该软件包正在被推送
          //执行推送升级所需的活动
        }
      }
    }
   
每个新的Apex类都需要一个测试类,所以这里是我们的例子:
    @isTest
    static void testInstallScript() {
      PostInstallClass postinstall = new PostInstallClass();
      Test.testInstall(postinstall, null);
      Test.testInstall(postinstall, new Version(1,0), true);
      List<Account> a = [Select id, name from Account where name ='NewAccount'];
      System.assertEquals(a.size(), 1, 'Account not found');
    }
   
使用Test类的testInstall方法来测试PostInstall类。什么进入该方法?你决定!

周到的自动化

自动化在工作时很棒。考虑如何最好地使用它与现有的和新的功能。

要增强现有功能,请使用安装后类自动将功能组件的任何新权限分配给现有用户。这样,每个人都可以不间断地使用软件包。

不要使用安装后的Apex脚本为新功能自动分配组件权限。相反,请提醒客户管理员注意这些功能,并让他们弄清楚细节。

安排您的升级

现在您已经定义了升级,现在是时间安排了。谁获得升级,什么时候?您可以交互式部署升级,或使用企业API自动升级客户。

以交互方式安排推送升级:

  1. 登录到您的包装组织。
  2. 从“设置”中,在快速查找框中输入软件包,然后选择 Packages.
  3. 选择要推送的托管软件包的名称。
  4. 在Package Details页面上,选择Versions并点击Push Upgrades。
    The Package Detail page, where you select Versions and Push            Upgrades.
  5. 点击 Schedule Push Upgrade.
    The Push Upgrade History section, where you click Schedule Push            Upgrade.
  6. 从 Patch Version 选择列表中选择一个软件包版本。
  7. 如果要安排开始日期,请在“计划开始日期”字段中输入日期。
    The Schedule Push Upgrade section, where you select a package            version and a start date for a push upgrade.
  8. 在“选择目标组织”部分中,选择要升级的组织。您已经升级的组织不会出现在此列表中。点击 Schedule.
    The Select Target Organizations section, where you use filters            to generate a list of orgs you want to update.

使用过滤器来选择要更新的组织列表。您可以通过以下方式过滤orgs:

  • 他们的部分或全名,或通过组织ID
  • 无论他们是沙箱还是生产组织
  • 他们已安装的软件包版本

使用企业API调度升级

当您根据各种规则和过滤器一次升级很多客户时,交互式调度变得困难。 Enterprise API允许您以编程方式安排和控制升级,并跟踪他们的进度。通过企业级API,您可以:

  • 使用SOQL查询查找使用您的软件包的客户
  • 计划推送升级到这些客户
  • 监视升级状态,并检查错误

该API为您部署升级提供了充分的灵活性。例如,您可以创建一个允许客户升级到新版本的Web表单。点击表单上的按钮可以安排这些客户的推送升级。

我们在这里没有描述如何使用企业级API–它涉及更多一点。 ISVforce指南有详细的步骤和代码示例,您可以使用它们来安排自己的推送升级。

跟踪更改

在您向客户发送更新时,您可以跟踪已经拥有最新版本软件包的用户。要查找收到推送升级的客户,请执行以下操作:

  1. 从您的开发组织中,单击 Setup.
  2. 在快速查找框中输入软件包并选择Packages.
  3. 点击包装的名称,然后点击 Push Upgrades.
  4. 单击目标的名称以查看“推送升级历史记录”页面。
    The Push Upgrade History page, where you select a org that you            are upgrading.
  5. 此页面包含有关推送升级的信息:其状态,任何计划开始日期,完成需要多长时间等等。
  6. 导航到组织部分,其中显示了所有要升级的组织的列表。
  7. 使用搜索框将组织过滤到您要搜索其升级状态的客户列表。
    The Job Details page, where you select the orgs you want to            track.

要筛选组织,请在搜索框中输入一个表达式。搜索部分或全部组织的名称或完整的组织ID。您还可以使用选取列表按推送升级的状态进行搜索。

改变:唯一不变

当你开发软件时,事情就会改变。 错误得到修复,功能被添加,算法和结构发展。 您已经在自己的开发团队中处理了更改。 现在您已经看到了如何将这些更改提供给您的客户。

Salesforce可以帮助您:

  • 通过为您提供两种机制来实现它们来构建您的更改:修补程序和升级
  • 通过合理的版本编号系统管理客户对变更的期望
  • 通过推送升级保持客户最新状态,从而简化维护工作

使用这些工具为您的客户提供及时和无缝的更新。 作为Salesforce的客户,他们期望软件即服务的所有好处。 保持SaaS的承诺,你可以让他们高兴。

应用升级(2)决定提供什么

学习目标

完成本单元后,您将能够:

  • 定义补丁和升级并给出每个例子。
  • 解释包版本号的重要性。
  • 描述如何创建补丁和升级。

生意兴隆!下一步是什么?

作为PartnerX的首席开发人员,您很自豪地报告说您的AppX在AppExchange上很受欢迎。您可以从客户那里获得反馈,并集思广益您的后续步骤。关于如何改进AppX的想法并不少见。

那么您优先考虑什么,以及您如何提供改进?回答这些问题需要计划。您的客户已经在使用您的解决方案,因此部分更改很难部署。理想情况下,您可以让AppX的升级过程像客户的其他体验一样令客户满意。

计划您的更新

您对产品所做的更新有两种:

  • Patches—轻微更改,如整形UX更新或错误修复,这些更改不会影响产品的行为。
  • Upgrades—对功能进行新的或重大的改变,改变产品的行为以及客户与之交互的方式。

假设你找到了你想修复的不一致的标签。或者,也许你只是在更新客户数据的公式中修复一个小故障。这些变化使得很多补丁。

对于您向客户承诺的令人惊叹的新功能,请使用升级。通过升级,可以进行重大更改,例如引入更好的工作流程或更改数据模型。

在我们进一步讨论之前,让我们看看一个简单的工具,用于向客户传达有关更改的信息:版本号。

软件包版本

我们都看到了软件版本号。广义而言,数字越大意味着更好的产品。无论如何,这就是希望!

Salesforce为版本化产品包提供了一个不错的简单格式。我们来看看最新版本的AppX:

AppX版本2.1.3

此版本号有三个部分:

  • 主版本号(2)。主要版本号的变化表明对产品进行大规模的全面更改。
  • 次要版本号(1)。当您添加功能或更改产品中的明显内容时,次要版本号会发生变化,但情况仍然与以前基本相同。
  • 补丁版本号(3)。每次使用修补程序更新产品时,修补程序版本号都会更改。

修补程序版本号易于管理 – 每次为包创建修补程序时它们都会自动更改。

当您对产品进行升级时,主版本号和次版本号会发生变化。主要和次要版本之间最大的区别在于,客户在进行次要版本升级时通常不需要改变他们使用应用的方式。

您的升级是重大更改还是次要升级?你决定。使用版本号来管理客户的期望。

你如何改变你的包装?我们先从补丁开始,因为它们是最简单的。

创建一个补丁

当您做出不影响底层数据模型或业务逻辑的更改时使用修补程序。修补程序只能在主要版本中创建,并且只能用于托管软件包。
当你创建一个补丁时,你需要在补丁开发组织中完成这项工作。这是一个特殊的组织,只允许不会破坏现有安装的更改。如果您是AppExchange合作伙伴,则可以在Salesforce合作伙伴社区中记录案例以获得正确权限后创建修补程序开发组织。

当您在补丁开发组织中工作时,您不能:

  • 添加新的软件包组件,Web服务或依赖项
  • 删除现有的软件包组件或弃用任何Apex方法
  • 更改API或动态Apex访问控制

有关限制的完整列表,请参阅ISVforce指南。

您使用包装组织创建补丁程序开发组织,而不是环境中心。创建后,您可以将修补程序组织连接到环境中心。

要创建补丁组织:

  1. 从包装组织中的设置中,在快速查找框中输入软件包,然后选择 Packages.
  2. 点击您的托管软件包,然后点击修补程序组织选项卡,然后点击New.
  3. 从“修补主要版本”选择列表中选择要修补的软件包版本。发布类型必须为“Managed – Released.
  4. 输入登录到您的补丁组织的用户名和相关的电子邮件地址。选择版本后会生成用户名(请参见下面的截图),但您可以更改它。电子邮件地址应该是您收到组织登录名和密码重置的主要电子邮件地址。这些特定于您的补丁程序开发组织。
    The Create Patch Development Organization section of the Package            Manager, where you enter a username and email address for your new            patch development org.
  5. 点击 Save.

修补程序开发周期

假设您正在对您的应用的2.0版进行更改。您创建一个补丁组织并在那里创建两个补丁,版本2.0.1和2.0.2。之后,您将这些修补程序合并到版本3.0中,您将其作为升级版本进行分发。

A patch is created from a major version, developed within a            patch development org, and merged back into the main development org            for a major or minor upgrade.

将修补程序合并到版本3.0中时,您已完成此修补程序组织。为3.0版的任何补丁创建另一个补丁组织。

有关详细信息,请参阅ISVforce指南。

创建升级

您已经对作品进行了重大更改 – 新的对象和业务逻辑,Lightning组件 – 并且您希望您的客户获得它们。为此,您可以为您的软件包创建升级。您只能升级托管软件包。

某些组件无法升级。 ISVforce指南提供有关哪些组件可升级的信息。

创建您的软件包的新版本

在开始之前,请确定您的升级是否值得主要或次要版本更改。这会提醒您的客户他们在做什么。

如果您要从软件包中删除组件,请在Salesforce合作伙伴社区中记录支持案例,以启用包装组织中的组件删除权限。您只能删除某些组件,详情请参阅ISVforce指南。

按照创建新托管软件包的方式创建升级:

  1. 在开发组织中的设置中,在快速查找框中输入软件包,然后选择软件包管理器。然后从可用软件包列表中选择软件包。
    The      Package Manager page, where you select your package.
  2. 您更改的任何组件都会显示在“组件”子选项卡中,以及任何新的依赖关系。要手动添加组件,请单击Add.
    The Package Detail      page, where you add components to your package.
  3. 选择适当的组件类型,选中所需组件旁边的复选框,然后单击添加 Add to Package. 下面我们添加活动和客户优先级自定义字段。
    The bottom of the Package Detail page, where you add custom components      and fields to your package.
  4. 准备好创建软件包时,请单击 Upload 以创建软件包的新版本。这将打开上传包页面。
    The Upload Package page, where you enter the details of your             package before uploading it.
  5. 在“版本名称”字段中,将该版本的软件包命名为与以前版本一致。版本号字段包含您可以覆盖的建议版本号。
  6. 再次单击 Upload 以完成软件包创建。
  7. 您将收到一封电子邮件,其中包含AppExchange上的软件包链接。与想要手动安装此升级的客户共享此链接。使用许可证管理应用程序中安装的用户列表来传播这个词。

简化,简化

软件包管理器允许您弃用软件包的旧版本。这样可以防止客户安装这些版本,尽管现有安装仍在继续。这使得维护更容易。

The Package Detail page, where you can deprecate older versions            of your app.

我们将在下一个单元恢复维护。

整理起来

您已做出所有要做的更改,严格测试它们,并上传您的托管软件包。你刚刚完成。在您将货物交付给客户之前,只剩下几件事情要做。

安全评论

如果您在AppExchange上拥有产品,那么您知道信任是Salesforce的首要任务。毕竟,您的应用通过我们的安全审查流程完成。您的修补程序和升级必须符合与您的应用程序相同的安全标准。

现在有一个好消息:您不必为每个补丁或升级都进行完整的安全审查。当您更新产品列表时,Salesforce安全操作团队会在24小时内审核您的代码。

要进一步了解我们的安全审查流程,请查看AppExchange安全审查模块。

更新您的应用列表

现在,您的闪亮新产品已准备就绪,现在可以更新您的AppExchange列表。

  1. 从Salesforce合作伙伴社区,导航到 Publishing. 然后选择你的列表。
    The Listings tab of the Publishing Console, where you select             your app’s listing.
  2. 导航到应用程序选项卡。在 “What package do you want to link to this listing?” 下,单击 Package.
    The App tab of the Publishing Console, where you update              your app’s listing.
  3. 从列表中选择您的软件包。
    The list of available packages that you select from.
  4. 点击 Save.
    The App tab of the Publishing Console, where you click             Save.

更新您的免费试用版

您正在使用Test Drive或Trialforce为您的客户提供免费试用产品,对吗?当然你是!让我们在试用期间更新您的试用版。你如何做到这一点取决于你提供的试用类型。

  • Installable Trial—您的客户在自己的组织中安装试用版。确保您的列表是最新的,并且您的客户可以简单地安装您的新版本。
  • Test Drive or Trialforce—在试用版组织中安装新版本,并创建一个新的试用模板。不要忘记更新任何测试数据并提交您的模板进行安全审查。

如果您没有向客户提供免费试用版,请前往AppExchange App试用版管理模块了解它们。

就是这样! 您的产品的新版本已准备就绪。 现在让我们来看看如何将更新分发给客户,SaaS风格。

应用升级(1)提供SaaS

学习目标

完成本单元后,您将能够:

  • 描述SaaS如何改变客户对软件更新的期望。
  • 讨论部署和维护单一版本产品的好处。
  • 列出一些您可以做的准备更新产品的事情。

平台的承诺

Salesforce客户知道他们有很好的表现。他们不必维护服务器和操作系统。他们不必知道如何设计,运行或优化关系数据库。他们甚至不需要备份自己的数据。

他们每年都会获得三个主要软件版本,并具有新功能和性能改进。他们获得了丰富的发行说明和培训材料(例如此工厂的Trailhead模块)。他们获得了AppExchange,这是一个与Salesforce无缝配合的产品市场。他们做生意所需的一切都在那里供他们使用。

伟大的期望

看到?企业软件不一定非常痛苦。它真的可以“只是工作”。这就是软件即服务(SaaS)的承诺。几年来,Salesforce已经向客户承诺了50多个成功的发布。即使是Salesforce平台的重大升级通常也会平稳安静地进行。

The logos of the myriad Salesforce releases that have shown our customers the promise of SaaS.

您的客户对我们平台上的产品有很高的期望。嘿,那就是成功的感觉!因此,当您更新产品时,您如何以保持SaaS承诺的方式将其提供给客户?

选择您的更新策略

更新有各种形式。修补程序是最小的一种更新 – 它们修复错误并对您的产品进行微调。升级是进行更大更改的更新。我们在下一个单元讨论补丁和升级。

当您更新产品时,您可以选择客户获得新版本的方式。有两种方法可以将它们放到他们手中:

  • Manual install—您的客户决定何时需要新版本并使用您提供的URL进行安装。
  • Automatic Install— 您将更新推送给客户,以便他们始终拥有最新版本的产品,并且每个人始终使用相同的版本。我们称之为推升级。

此时,您可能想知道为什么我们提供自助服务选项。这不是Salesforce自己发布版本的方式,它当然也不是“无缝”。为什么不用Salesforce的方式做事情,并以锁步方式更新每个人?

现实情况是:Salesforce在成功的低戏剧升级方面拥有悠久的历史记录。客户相信Salesforce可以正确执行发布,并快速解决流程中可能发生的任何问题。但是,这些相同的客户在适应AppExchange合作伙伴的自动更新之前需要更多的说服力。

让我们来谈谈推送升级的好处,以便传播良好的词汇。

推升级保持简单

我们建议您尽可能使用推送升级来分发您的产品的新版本,并仅对坚持使用它的客户使用自助更新。

推送升级使您的所有客户都保持在同一版本的应用程序上。这对您和您的客户都有好处。为什么?考虑另一种方法:支持应用程序的多个活动版本。当你维护多个版本时,事情变得复杂:

  • 您的支持团队必须跟踪每个版本的功能和修复情况,以便他们可以针对客户问题做出适当的回应。
  • 您需要维护多个版本的文档和培训材料。
  • 当你修复一个bug时,你可能不得不将它移植到多个版本。

相反,当您使用推送升级来让客户保持最新状态时,您可以避免所有额外的工作。

不要违背你的承诺

不言而喻,但我们仍然会说:不要破坏你的应用程序或你的客户的组织。当然,在不损坏客户的情况下更新产品可能会非常棘手。 Salesforce为您提供了一些便利的工具和一些边界,可以帮助您走上正确的道路。

自动化过程

有时,更新要求您在安装新产品版本时,在客户的组织中完成一些工作。也许你想在安装之后验证一些数据或在组织中进行一些清理。

你可以在你的应用中包含一个按钮来完成这项工作,但如果客户没有按下它,工作就不会发生。我们建议您在安装过程中自动完成工作,而不是牵涉到客户。当你设置你的软件包时,包括脚本来做到这一点。这些脚本可以更新数据和某些元数据。

例如,假设您在某个Apex代码中发现了一个计算存储在字段中的值的错误。作为更新的一部分,您可以修复该错误并运行脚本,该脚本还修复了修复之前生成的所有错误值。

保留现有行为

当您开始使用托管软件包时,可能您注意到无法删除已添加到软件包的某些组件(请参阅ISVforce指南以获取列表)。如果您将自定义对象或字段添加到包中,然后将该包上传到AppExchange,那么您现在就坚持使用它。

这看起来令人沮丧。但通过阻止您删除组件,Salesforce可帮助您将SaaS承诺保留给客户。他们知道他们可以依靠一定的稳定性 – 他们可以定制和构建您的解决方案,而不用担心突然的变化。

假设Salesforce不会阻止您删除组件。作为应用程序更新的一部分,您可以从托管软件包中删除自定义对象。如果您的任何客户在报告中使用该自定义对象,或者已经使用新字段进行扩展,那么它们会带来一个粗暴的惊喜。他们收到你的更新,自定义对象消失,东西破裂。混沌!

另一方面,我们知道情况发生了变化 – 尤其是在软件方面。有时最好删除一个组件,无论是修剪功能还是重新设计应用。别担心,我们不会站在你和你的目标之间。有许多方法可以让你做出任何需要的更改 – 甚至删除自定义对象。我们会在稍后的单元中向您展示这些。

一点准备工作要走很长的路

我们提到了Salesforce在低电视剧发布和更新方面令人印象深刻的记录。我们的秘密是什么?细致的测试。这不是太令人兴奋,但确实有效。更多的测试意味着少戏剧。

有时,合作伙伴非常关注他们出色的新功能,以便在测试更新时掩饰一些细节。以下是一个不完整测试过程的示例:您将升级后的应用安装在新创建的空测试组织上。如果它在那里有效,那很好,对吧?如果你的所有顾客都是从新鲜起家开始的,是的。

但是,大多数现实世界的客户在任何时候都处于业务中间。他们已经将升级安装到一个已经有一百万个组件的组织中。因此,测试您的凌乱,真实的组织和原始升级。

无缝无忧地部署您的更新

当您的软件自行更新时,您的客户不能只按“暂停”他们的业务。这不是SaaS承诺的一部分。无法保证任何事情都不会失败,但通过考虑更新如何影响客户,您可以最大限度地减少混乱。

  • 考虑你的更新的影响。您是否在改变客户使用产品的方式?
  • 首先在内部测试您的更改。使用各种各样的组装测试组织,而不仅仅是空的测试组织。
  • 考虑在你的部署中使用层:你的高级用户首先得到更新,其次是其他人。 Salesforce使用此流程,它有助于我们理解对真实客户的影响。

现在我们来看看您可以提供更新的不同方式。