#salesforce開発モデル
ざっくり言うと、三つ開発モデルがある。
##・変更セット開発モデル
開発環境の設定 UI で変更を作成し、その変更を別の環境に移行します。
チームのリリースアーティファクトは、本番組織に存在するメタデータからの変更部分 (差分、デルタ) の集合体です。
変更セットを使用して新規コンポーネントや変更済みコンポーネントを追加できるのに、変更セットを使用してコンポーネントの削除や名前変更(破壊的な変更)ができないことです。
・コンポーネントを削除する場合は、対象組織の Web インターフェースを使用します。
・コンポーネントの名前を変更する場合は、対象組織でコンポーネントを削除してから、変更セットに新しいコンポーネントをアップロードします。
変更セットをアップロードした後に変更する必要がある場合は、変更セットをコピーする必要
変更セットの検証：リリースの予行演習
変更セットのリリース失敗の原因：変更セットに連動コンポーネントが含まれていないことです。
##・組織開発モデル
Salesforce CLI利用、バージョン管理システム (VCS) に統合して、リリースする。
変更が上書きされる前に、カスタマイズの競合を特定できます。
Sandbox、Developer Edition (DE) 組織、Trailhead Playground、さらには本番組織など、ソース追跡されない組織での作業を可能にし、コードを直接取得して（package.xml）デプロイします。
GitHub利用
##・パッケージ開発モデル
パッケージは関連するコードやカスタマイズのグループであるリリースアーティファクト（リリース神器）です。と組織開発モデルの区別はバージョン管理がある。
特定のパッケージを所有するチームを割り当てることができます。複数の開発チームが別々に開発を行い、組織への更新のリリースではなくパッケージのリリース用にビルドできます。
自己完結型のアプリケーションやライブラリを作成して、単一のパッケージとして組織にデプロイすることができます。これらのパッケージは通常、スクラッチ組織のようなソース追跡される組織で開発されます。この開発モデルでは、組織のソース追跡、ソース管理、および継続的インテグレーションや継続的デプロイメントを使用します。
Salesforce CLI、Salesforce DX利用
###未管理パッケージ
未管理パッケージは、通常、開発者にアプリケーションの基本ビルディングブロックを提供するために、オープンソースプロジェクトまたはアプリケーションテンプレートを配布する場合に使用します。未管理パッケージからコンポーネントがインストールされると、コンポーネントはインストールされた組織で編集できるようになります。未管理パッケージを作成してアップロードした開発者は、インストールされたコンポーネントを制御できず、これらのコンポーネントを変更またはアップグレードできません。Sandbox から本番組織へのコンポーネントの移行に未管理パッケージを使用しないでください。代わりに、変更セットを使用してください。
パッケージのアップロードに使用した組織がまだ存在する場合にのみ、管理パッケージをインストールすることをお勧めします。この組織が削除されている場合、管理パッケージはインストールできません。
###管理パッケージ
管理パッケージは通常、アプリケーションをカスタマーに配布、販売するために Salesforce パートナーが使用します。これらのパッケージは、Developer Edition 組織で作成される必要があります。AppExchange およびライセンス管理アプリケーション (LMA) を使用して、開発者はユーザベースのライセンスをアプリケーションに対して販売および管理できます。また、管理パッケージは完全にアップグレード可能です。シームレスなアップグレードを実現するために、オブジェクトまたは項目の削除などの特定の破壊的な変更は実行できません。
管理パッケージには次のような利点もあります。
・Apex の知的財産の保護
・API アクセスが可能なコンポーネントの組み込みのバージョン管理サポート
・前のバージョンを分岐およびパッチする機能
・登録者へのパッチ更新のシームレスな転送を行う機能
・インストールで競合が発生しないようにすべてのコンポーネントに一意の名前を指定
###特徴：
・メタデータがパッケージバージョン毎に管理され、アップデートやメンテナンスが容易になる
・変更に対する柔軟性(メタデータは本番組織で直接変更可能)
・開発リソースがパッケージ単位で整理される事で開発効率が向上
・不具合のスコープを限定しやすくする
・名前空間が不要であり、既存のインテグレーションに影響を与えない
###パッケージ開発方法
####事前準備
以下の設定を行ないます。
ローカル環境
Salesforce CLI(v44.0以上)のインストール
Salesforce環境
私のドメインの有効化
設定 > クイック検索から「Dev Hub」を検索し以下の設定の有効化を行います。
Dev Hub を有効化
ロック解除済みパッケージ (正式リリース) と第二世代管理パッケージ (ベータ) を有効化
####1.パッケージの開発
スクラッチ組織の作成
まずはスクラッチ組織を作成します。
sfdx force:org:create -s {スクラッチ組織の別名}
※管理を容易にする為、スクラッチ組織の別名の設定を推奨
ローカルからスクラッチ組織へのソースのPush
sfdx force:source:push -u {ユーザ名 or エイリアス}
スクラッチ組織からローカルへのソースのPull
sfdx force:source:pull
パッケージの作成
sfdx force:package:create -n {パッケージ名} -t Unlocked -r {パッケージのリソースのPATH}
####2.リモートリポジトリに変更を反映
gitなど任意のバージョン管理システムが利用可能です。
####3.CIプロセスの実行
CIツールを使用して構文チェックや自動テストによる不具合の早期検知を行います。
コード解析
sfdx force:lightning:lint {チェック対象ソースpath}
自動テストの実行
Apex単体テスト
sfdx force:apex:test:run
Lightning Testing Servies
sfdx force:org:open -p {テストアプリのpath}
※Lightnng Testing Serviesについてはこちらを参照ください。
####4.SandBoxでのテスト実行
パッケージのインストール
sfdx force:package:install -u {ユーザ名 or エイリアス} -p {パッケージ名}
####5.本番組織へのパッケージのインストール
パッケージのインストール
sfdx force:package:install -u {ユーザ名 or エイリアス} -p {パッケージ名}
##salesforceの開発方針
開発環境と本番環境分離、本番環境のApexコード変更できません。
##リリースのカテゴリー
・パッチ
バグ修正や簡単な変更。レポート、ダッシュボード、リストビュー、メールテンプレートなどの簡単な変更です。
・マイナー
1つのビジネスプロセスのみに影響する新しいワークフロールールやトリガなど、影響が限定的な変更。通常こうしたリリースはテストが必要ですが、トレーニングや変更管理は限られています。一般に、マイナーリリースの変更は数週間以内に実施されます。
・メジャー
1つ以上の連動関係を伴う変更など、多大な影響のある変更。これらのリリースは、ユーザエクスペリエンスやデータ品質に大きな影響を及ぼす可能性があるため、綿密なテストやトレーニング、慎重な変更管理を要します。メジャーリリースは通常、四半期に1回 (Salesforceは年に3回) 実施されます。