特殊时期,大家一定要保重身体。增强自身免疫力,一切都会过去,一起加油!!!

一次项目Release(リリース)的过程

Salesforce zchao 1492℃ 0评论

一个项目从开始到发布大概分为以下几个步骤。

 

当然前期会有很多准备,市场调研,功能技术可行性分析等等,

需要能够掌控全局的人来做,需求分析,前期的规划至关重要,

直接影响后面项目能否顺利进行下去。

 

1,项目启动(Kick Off)

2,项目创建(Create)

3,项目开发(Dev)

4,项目测试(Test)

5,用户验收(UAT)

6,项目发布(Release,sandbox到production)

7,项目维护(Maintenance,现有功能维护,新功能追加)

 

这次主要想介绍一下,项目Release的过程,是如何准备以及发布时遇到的问题,如何解决,最后发布完了的对应。

 

主要是要做好Release的手顺书,因为操作相对较多的时候,我能们记忆有限,不可能凭空想象这操作,

相反,如果我们有可以参考的手顺,一步一步来,那不是更好吗,也避免遗漏一些设置等。

 

最近项目形式类似敏捷开发,基本测试内容做的很少,主要通过两个人Double Check,(W Check)为主,

也就是两个人同时进行动作确认,如果基本业务流程没有问题,那也就是通过了。

为什么说是敏捷开发类型呢?先看一下敏捷开发的基本概念:

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、

与个人互动,而不是与流程和工具互动
可以运行的软件,而不是综合文档
与客户合作,而不是合同谈判
响应变化,而不是遵循计划

这次基本满足上面四种情况。

与一起开发的人,或者上面的PM,Leader多次沟通交流,不只是看业务流程与现有工具。

做出来的系统可以运行,每一次变更,客户都可以操作,不只是让客户查看文档,当然文档也必不可少,在符合业务的前提下,稍后也可以整理。

与客户合作,柔软性的变化,不只是通过合同交流,过于生硬。

虽然事先会做好一些预设的功能,但是随着时间的推移,业务需求,甚至客户喜好,也会有所变化,这样的情况,也是需要即使更换计划,灵活对应。

 

接着说准备手顺书,手顺书大概包含的内容,也就是这次需要Release的内容,

有一部分可能是需要事先设定的在Production中,

有一部分可以通过Change set发布到Production中(或者需要开发IDE,用metadata API形式发布),

还有一部分,比如Profile中的部分设定,Change set不能发布的问题,需要手动设定在Production中(或者Ant 移行ツール可以发布Profile中的部分设定,需要谨慎操作)。

https://developer.salesforce.com/docs/atlas.ja-jp.apexcode.meta/apexcode/apex_deploying_ant.htm

当然也许我们会有新增加的部分功能,忘记记录了,那么确实是一件麻烦的事情,需要用工具在sandbox和production中进行对比。

找出其中不同的部分,在增加到手顺书中。我这次用的是WinMerge比较工具。可以比较文件夹和文件,会用颜色标出两个文件之间的差异。

https://winmerge.org/?lang=ja

这次也是比较sandbox和production的Metadata API,

首先可以获得两个环境的Metadata API,方法很多了。

可以通过VSCode获取,也可以用google插件下载。

VSCode获取Metadata API可以参考下面

VSCodeでSFDC環境構築、複数の方法でメタデータを取得ーVSCode(利用できるPackage.xmlをアップロード)

 

google插件:

Salesforce inspector

https://chrome.google.com/webstore/detail/salesforce-inspector/aodjmnfhjibkcdimpodiifdjnnncaafh

 

下载即可。

 

WinMerge

 

Object的不同。

 

上面可以发现,Production中缺少一个字段。

可以对比确实也很困难,但是事先没有做好手顺,遗漏的问题,也没有办法,如果大家有更好的办法,请评论留言,互相讨论。

 

顺便推荐几个SFDC相关的插件,

Boostr for Salesforce

– Ability to search when adding items to a change set
Filtering by type when adding to a change set
– Showing all items of a given type on one page when adding to a change

在追加change set时,非常方便,可以根据类型检索需要的Component,

 

 

Salesforce DevTools

・Exporting Objects Field Definition to Excel file.
・Exporting Objects Page Layout to Excel file.
・Salesforce data modal (ERDs) generator.
・Display fields API name on Salesforce object detail page.

 

可以导出Object定义书等等。

 

 

 

还有很多很实用的工具,配合着使用可以提高效率,毕竟可以说【时间就是金钱】。

 

 

 

接着说稍微具体点的手顺书内容,

Release前的准备,比如环境的设定,

Deployment Settings

需要事先设置好,产品环境可以接收开发环境发送过来的Change set。

 

一些Package等,也需要提前安装在Production中,

Files connect for Salesforce

Box for Salesforce

OUTLOOK for lightning

Email-to-Case Settings

API名变更等,如有特殊需要。

 

Change set做成也是在Release前需要准备好的,因为当天需要直接发布。

 

关于Change set的一览列表内容,需要知道哪些组件可以加,哪些不可以追加:

比如Profile中的Field的FLS访问相关的设置是无法通过Change set过去的。

更改集中可用的组件:

https://help.salesforce.com/articleView?id=changesets_about_components.htm&type=5

做好分类,方便添加。

 

以本次追加的Component为例,

Action

Apex Class

Apex Trigger

Button or Link

Compact Layout

Custom Field

Custom Object

Custom Report Type

Dashboard

Dashboard Folder

Flow Definition

Global Value Set

Group

Lightning Page

List View

Page Layout

Permission Sets

Record Type

Report

Report Folder

Role

Sharing Criteria Rule

Tab

Validation Rule

Visualforce Page

Workflow Field Update

Workflow Rule

Profile

Profile也可以追加,但是如果Profile很多,也有许多新增加的Field,那么后期的Field的FLS工作,会很繁琐。

所以这时候建议在Production中去复制一个基本完整的Profile,然后再一个一个复制更名名称,再去更改Field。

会节省很多时间。

 

关于Report和Dashboard的发布,稍微有一点问题,就是正常都会存储在相对应的文件夹下面,

所以可能还需要自己事先创建对应的文件夹,否则会提示,不存在的文件夹之类的问题。

 

然后就是一些手动设定部分了,需要直接在Production中设置。

我们设置的部分,手顺书上的内容都要和客户说好,告诉他们进行的状态等,因为可能会与客户有一些交互。

可能细致到每一分做了什么样的操作,最好都留下证据,截图也许很值直接。

 

简单看一下,本次手动设定的内容有什么

アプリケーション設定

Mobile Only非表示

プロファイル設定

Sharing Settings

標準項目設定

Convert機能(マッピング)

検索レイアウトの設定

Sales Processesの設定

History Trackingの設定

Feed Trackingの設定

不要Roleの手動削除

Hierarchy Columnsの設定

Opportunity Contact RoleのRole PickList

ProcessBuilder有効化

等等。

其实每一部分的手动设定都要做好手顺,或是文本说明,或是图片表示。这些先后顺序,也是根据项目不同,有所不同,只要合理不产生冲突即可。

 

 

手动设定部分就一步一步来吧,关键是change set部分不出问题。

 

我们在sandbox中做好了change set,

Outbound Change Sets

需要upload到Production中,

然后在Production中,

Inbound Change Sets

进行Validate,成功之后,才可以Deploy。

 

如果Change Set内容很多,很少会一次验证通过,会遇到各种问题,当然都是具体问题具体分析。

 

比如,遇到了下面的问题,

说明没有对应的文件夹。

下面的问题,是原来的类和测试类出现了问题,测试类的覆盖率要求达到75%以上,基本上也给出了具体错误位置。

 

其实上面的问题,是在项目正式发布的前一天发生的,当时只是做了验证的过程,所以在发布之前最好做到验证的步骤。

 

最后看一下,Deployment Succeeded的画面。

 

之后会有一些数据移行,这些更需要谨慎操作,数据真的太重要了。

 

上面写了关于Release的大致过程,当然项目不同,准备作业会不同。

如果有疑问的地方,可以留言,希望大家多多指教。

 

 

我在故我思,我思故我在。

 

 

转载请注明:zchao博客之家 » 一次项目Release(リリース)的过程

喜欢 (10)or分享 (0)

您必须 登录 才能发表评论!