組織、開発モデル

Developer は一日、200MB、Developer proは一日 、1GB、pertcial copy は5日、5GB、Fullは29日　組織と同じ容量

レコードがオブジェクトごとに最大1万件コピーできる。

本番組織からコピーして作成するオブジェクトをまとめたもの、Partcal Copy、Fullで使用可能

メタデータに対して変更されたものをまとめたもの

変更セットを受信する環境のリリース設定が必要

Sandboxを含む同一環境間で利用可能

10日

標準項目、未整理公開レポートフォルダ、非公開フォルダに格納されているレポートやWeb-to-リード、Web-to-ケースなど

タブやオブジェクト、項目を表示するための権限をプロファイルに設定するために、権限も含めて変更セットに入れなければならない。

データ型の変更を行なっている

管理パッケージ、未管理パッケージ

配布に最適、ソースがみえない(保護)、アップグレード可能

一度の配布で済む場合などに利用、コードが見えるのでサンプル集の配布など

だいたい標準の機能がかかわるものだったり、標準項目のカスタマイズだとか 取引先チーム、カレンダー、カスタマイズ可能な標準項目での自動採番 こういうのは出荷できない！

変更セットを同一組織間でやりとりしながら開発するモデル。 Developerで開発して、Developer proでリリーステスト、Fullでユーザ受け入れテスト

変更セットでは追加しかできないので、削除は直接組織内から消すしかない。(SalesForceのWebインタフェースで直接削除)

カスタム項目など、対象のコンポーネントも含める必要がある。 ちなみにパッケージ型ではコンポーネントも含めて丸ごと出荷となるので、上記の考慮は必要ない ただしプロファイルや権限セットの出荷は 変更した差分のみを出荷できないので、 すでに出荷先でカスタマイズしている場合は上書きしてしまうので注意 →権限セットや権限セットグループを活用せよ

受信側:リリース設定にて、送信側の環境を選択し、変更着信を許可する。 送信側:送信変更セット画面にて、送信するメタデータを指定し、送信する。 受信側:受信変更セット画面にて、受信したデータをリリースする。 https://opt-p.co.jp/blog/salesforce-sfdc/post-1537/

カバー率全体で75％、10日以内

変更セット開発モデル、組織開発モデル、パッケージ開発モデル

組織開発モデルは、Salesforce DXツールとソース制御を使用して変更を管理するための方法です。 このモデルでは、Sandbox、Developer Edition (DE) 組織(開発者が無料で利用できる環境) 、Trailhead Playground、または本番組織など、ソース追跡されない組織での作業を可能にし、コードを直接取得してデプロイします。 つまり、自分たちで変更を追跡する必要がある。 リリースアーティファクトでやりとり、 GITで追跡、 CLIを利用した変更セットを利用しない開発モデル developで開発テスト(ブランチ作成→コミット→ブランチをオリジンにプッシュ→プルリクエスト)、 develop proで変更資産をまとめて、partialでリリーステスト(ユーザ受け入れ)、fullでユーザトレーニング

レコードタイプを利用している場合は、レコードタイプのほうで実際の選択値を定義しているため、レコードタイプも変更セットに含める必要がある

言語翻訳と、翻訳されるコンポーネントそのものも変更セットに入れないと適用されない。 なので、翻訳されるコンポーネントがパッケージ外などであれば、手動で設定しないといけない

公開グループの中身はリリースされないので手動設定がいる ちなみに 公開グループとは、ユーザやロール、テリトリー、グループによって構成されているユーザの集合体です。

mdapiのほうはトランザクションである sourceのほうはトランザクションじゃないので、失敗しても成功した分はリリースされてしまう

パッケージ開発モデルは、メタデータとソースコードの整理とバージョン管理に焦点を当てた広範な開発手法である。 ロック解除済みパッケージは、つまりパッケージ開発モデルのことをいっている。

メタデータAPI、ToolingApi、SoapApiなどいくつかのSalesForceApiを組み合わせたもの。Ant移行ツールの機能をサポート。 メタデータタスクをスクリプト化できる！

Salesforceでの開発に使用される2つの異なるタイプの組織です。 以下は、それぞれの主な違いをまとめたものです。 スクラッチ組織: 一時的で設定可能な環境で、ソース駆動型の開発に適しています。 あらゆる設定が可能で、機能や設定の異なるさまざまなSalesforceエディションをエミュレートできます。 有効期限は最大30日で、デフォルトでは7日に設定されています。 ソース追跡がデフォルトで実行され、開発者の生産性とコラボレーションを促進します。 Salesforce CLIまたはIDEを使用してブラウザーでログインせずに開くことができます Developer Edition組織: 無料で利用できる永続的な環境で、Enterprise Edition組織で利用可能な多くの機能にアクセスできます。 開発、ステージング、テストに適していますが、時間の経過とともに古くなり、ストレージにも制限があります。 定期的にログインしていないと期限切れになることがあります。 ソースの追跡が有効化されておらず、DevOpsセンターの開発環境としては使用できません スクラッチ組織は、特に短期間のプロジェクトや機能のテストに適しており、新しい開発環境を素早く作成することができます。 一方、Developer Edition組織は、長期間にわたる開発や学習に適しており、永続的な環境を提供します。

ステージング環境やユーザ受け入れテストや、パッケージのリリーステストなどを行う。

ソース形式のメタデータのローカルディレクトリ構造

パッケージのソースを丸ごと管理、複数パッケージも管理可能。 スクラッチ組織を作成するための設定ファイルをもつ。

パッケージ開発モデルのことで、GITにいれたソースが一番信頼できるソースだからということ。(そこから出荷してるから) 変更セットの場合は、一番信頼できるのは、本番環境となる

force:source:status このコマンドは、SalesforceプロジェクトのソースコードとSalesforce組織の間で行われた変更を追跡するために使用されます。 未コミットの変更の検出: ローカルのソースコードとSalesforce組織の間で行われた変更を検出し、それらがまだバージョン管理システムにコミットされていないかどうかを確認できる。 変更の同期: force:source:pullやforce:source:pushコマンドと組み合わせて使用することで、ローカルの変更をSalesforce組織にプッシュしたり、Salesforce組織の変更をローカルにプルしたりすることができます。 競合の検出と解決: ローカルとSalesforce組織の間で競合が発生した場合、それを検出し、適切な解決策を提案します。

ローカルリポジトリを作成し、スクラッチ組織で開発(ソースやメタデータは転送しておく)、コミットし、ローカルリポジトリごとオリジンへpush→新たなスクラッチ組織でコンパイルテスト、sandboxへパッケージ適用してテスト

CI(Jenkins)

本番組織からメタデータを分離できない状況で、パッケージ化する際に利用される。 通常はパッケージバージョンの作成中にメタデータ検証が行われるが、 組織連動ロック解除済みパッケージでは、パッケージインストール中にメタデータ検証を行うため、メタデータがインストール先の環境にあれば、問題なくインストールされるというもの。 プラスアルファパッケージはこれかも。。？

メタデータコンポーネントは同時に複数パッケージに存在できないため、ベースのメタデータをパッケージとしてまとめて、共有することができるパッケージ

本番組織の最新の状態を反映させるという観点で考える。 以下二つ 本番環境の設定変更後: 本番環境での重要な設定変更やリリースが完了した後、フルサンドボックスを更新して、本番環境と同じ条件を維持することが望ましいです。 受入テスト完了後: 重要な開発フェーズや受入テストが完了した後にフルサンドボックスを更新することで、最新の本番環境の状態を反映させることができます1.

追加した項目や追加したアクションも含めないといけないらしい

主従関係項目も入れる必要がある https://atsudayo.com/changeset-point/#index_id1

レポートタイプ レポートタイプが古いとレイアウトに新規項目がない状態なので、エラーになる

組織と同じ容量であるフルサンドボックス ステージング環境の用途もある ただ、アーカイブされたレコードはコピーされない

部分サンドボックス

できない！！！

変更セットは同一組織間 未管理パッケージは、異なる組織で利用。

新しいIDになる！

変更される .サンドボックス名がつく ユーザ名はサンドボックスで一意になるともいえる。

できない。オブジェクトの選択のみ

運用や開発者向けの組織で、個人で作成可能 トレイルヘッドの組織がそう。

未管理パッケージ

管理パッケージなら、自動的にアップグレード可能だが、未管理パッケージの場合は、一度アンインストールしてから入れ直さないドアップグレードできない

カウントされない！ 未管理パッケージはされるけど。

同じブラウザを使用して複数のSalesforce組織で作業できる。 外部のIDプロパイダーを利用したシングルサインオン(salesforceへログイン)を有効化できる。 ソーシャルサインオンを有効化できる。 組織のログインページをブランドでカスタマイズできる。

まず、私のドメインが有効化されている必要があるが、 私のドメインの認証設定のとこで編集することができるを

出荷する項目の項目レベルセキュリティをプロファイルに一括追加ができる設定があるらしい

できないので、手動でやる必要がある。 プロファイル設定は項目自体とプロファイルの二つが必要であり、標準系のものは変更セットに入れられないので、手動でしかできない

sfdx force:source:convert これコマンドでは、出力ディレクトリにマニフェストpackage.xmlも出力してくれる。 zip化は jarコマンドとかで。

宣言型開発。 プログラム型はIDEがつかい、 宣言型ではポイントあんどクリックなので、画面での開発みたいなところをやるのにむいている。

どちらもされる。 sfdx force:source:status

スクラッチ組織とDeveloper Edition組織は、Salesforceでの開発に使用される2つの異なるタイプの組織です。 以下は、それぞれの主な違いをまとめたものです。 スクラッチ組織: 一時的で設定可能な環境で、ソース駆動型の開発に適しています。 あらゆる設定が可能で、機能や設定の異なるさまざまなSalesforceエディションをエミュレートできます。 有効期限は最大30日で、デフォルトでは7日に設定されています。 ソース追跡がデフォルトで実行され、開発者の生産性とコラボレーションを促進します。 Salesforce CLIまたはIDEを使用してブラウザーでログインせずに開くことができます Developer Edition組織: 無料で利用できる永続的な環境で、Enterprise Edition組織で利用可能な多くの機能にアクセスできます。 開発、ステージング、テストに適していますが、時間の経過とともに古くなり、ストレージにも制限があります。 定期的にログインしていないと期限切れになることがあります。 ソースの追跡が有効化されておらず、DevOpsセンターの開発環境としては使用できません スクラッチ組織は、特に短期間のプロジェクトや機能のテストに適しており、新しい開発環境を素早く作成することができます。 一方、Developer Edition組織は、長期間にわたる開発や学習に適しており、永続的な環境を提供します。 どちらの組織も、本番環境で直接開発することはできません。開発者は、プロジェクトの要件に応じて、これらの組織を適切に選択する必要があります。

画像の通り 組織情報の設定 財務情報の設定 サポート情報の設定ができる

ロケール(地域、言語、タイムゾーン)のデフォルト値 使用可能なディスク容量(データ、ファイル) 現在のライセンス数 マスター通貨

会社によって会計年度のタイミングが異なるのでその設定ができる。 これはレポートとかで利用され、設定した会計年度での絞り込みができるようになる。

会社のサポート部門の営業時間のセットを作成することができる。 朝6-夜18時までみたいな。 またサポートする部門やプランなどによって営業時間が異なる場合や、タイムゾーンが異なる場合は、複数の営業時間を作成することができる。 ここではただ営業時間がどれくらいであるという定義のみを行う。 営業時間を登録する際は、 タイムゾーンと営業時間の範囲を曜日ごとに設定して登録する。 エスカレーションルールなどの機能でこの営業時間が使われる