最初のロック解除済みパッケージの構築

学習の目的

この単元を完了すると、次のことができるようになります。

パッケージ化のための CLI コマンドに慣れる。
基本的なパッケージ化の使用事例を説明する。
DreamHouse LWC サンプルアプリケーションをパッケージ化して、Trailhead Playground にインストールする。

メモ

日本語で受講されている方へ
Challenge は日本語の Trailhead Playground で開始し、かっこ内の翻訳を参照しながら進めていってください。Challenge での評価は英語データを対象に行われるため、英語の値のみをコピーして貼り付けるようにしてください。日本語の組織で Challenge が不合格だった場合は、(1) この手順に従って [Locale (地域)] を [United States (米国)] に切り替え、(2) [Language (言語)] を [English (英語)] に切り替えてから、(3) [Check Challenge (Challenge を確認)] ボタンをクリックしてみることをお勧めします。

翻訳版 Trailhead を活用する方法の詳細は、自分の言語の Trailhead バッジを参照してください。

パッケージ開発が優れている理由

パッケージ化は、Salesforce Platform 開発者にとって、最も画期的な機能の 1 つです。スライスした食パンや、携帯電話、動画ストリーミングサービスのような、よく知られた衝撃的なイノベーションと同じようなものです。それでは説明が足りないという方のために、これまでに学習した主要な利点をまとめましょう。パッケージ開発には、次のことがあてはまります。

ソフトウェア開発ライフサイクルに関するベストプラクティスに従う。Salesforce DX の機能との互換性があり、プロジェクト、CLI コマンド、およびスクラッチ組織は、特にパッケージ化を考慮して構築されています。
ライフサイクルフェーズ間で追跡しているすべての変更を、バージョン管理されたアーティファクトにカプセル化する。
新しい機能の要求への対応を簡単にする。パッケージでコンポーネントを追加、更新、削除するだけです。
監査履歴が改善されて、本番組織で実施した変更を簡単に追跡、確認できるようになる。
ソースを整理する。どのコンポーネントがどのアプリケーションおよび機能に属するのかを非常に簡単に確認できます。
反復型およびモジュール形式開発を促進する。
ロック解除済みパッケージ間の相互連動関係をサポートする。1 つのロック解除済みパッケージは、複数のロック解除済みパッケージおよび第一世代と第二世代の管理パッケージと連動できます。
CLI コマンドをパッケージ化すると、リリースパイプラインの各ステップを完全に自動化できるようになるため、継続的インテグレーションと継続的配信をサポートする。

簡単なパッケージ化の使用事例

ロック解除済みパッケージは、社内用のビジネスアプリケーションに非常に適しています。たとえば、次のような場合です。

従業員が経由を提出するために使用できるアプリケーションを構築するように、財務ビジネスグループが IT チームに望んでいる場合。チームは、ロック解除済みパッケージを使用して、アプリケーションを開発、配信することを決定します。
従業員が採用候補者を参照するために使用できるアプリケーションを構築するように、人事チームが IT チームに望んでいる場合。従業員は、求人掲載、知り合いの紹介、紹介ボーナスの取得のために紹介アプリケーションを使用します。チームは、ロック解除済みパッケージを使用して、アプリケーションを開発、配信することを決定します。

これらそれぞれで、まったく新しいプロジェクトを開始します。すべてのソースは、Salesforce DX プロジェクトにソース形式で含まれます (また、バージョン管理システムにコミットされます)。これらのアプリケーションいずれかを配信する準備ができたら、スクラッチ組織または Sandbox でテストできるロック解除済みパッケージを作成した後、本番組織にインストールします。また、チームが新しい機能を必要とするときは、機能を追加して、新しいパッケージバージョンを作成できます。簡単です。ですね。

パッケージ開発の利点についてわかったところで、ロック解除済みパッケージの作成方法を説明していきましょう。

環境の設定

本題の前に、新しい Trailhead Playground を設定し、Dev Hub とパッケージを有効にしましょう。

メモ: このセクションの手順を一緒に実行する場合、ハンズオン Challenge を開始するときにもう 1 つ新しい Trailhead Playground を作成する必要があります。

新しい Trailhead Playground を作成するには、この単元の最後にあるハンズオン Challenge に移動します。[Launch (起動)] ボタンの左にある Playground 情報をクリックします。
次に、[Create Playground (Playground を作成)] を選択します。

メモ: 既存の Trailhead Playground を再利用することもできますが、新しい Playground から開始することで一から作業することができます。
新しい Trailhead Playground を作成したら、[Launch (起動)] をクリックして Playground を開きます。Playground のユーザー名とパスワードの両方を必ず確認しておいてください。次のステップでこの情報が必要になります。
「Trailhead Playground のユーザー名とパスワードの取得」を参照してください。
Trailhead Playground の [設定] から、[クイック検索] ボックスに「Dev Hub」と入力し、[Dev Hub] を選択します。[Dev Hub を有効化] をクリックして、[ロック解除済みパッケージと第二世代管理パッケージを有効化] をクリックします。
GitHub アカウントがない場合は GitHub アカウントを作成します。
コンピューターに Salesforce CLI をインストールします。

DreamHouse ソースコードの取得

デモのために、ビジネスチーム向けに DreamHouse LWC アプリケーションを構築および配信していると仮定します。

現在、Salesforce DX の機能とツールを使用している場合は、すでに DreamHouse LWC サンプルリポジトリについて知っているでしょう。DreamHouse LWC は、Salesforce プラットフォームで使用できる多くの機能が組み込まれたスタンドアロンアプリケーションです。Lightning Web コンポーネント、Apex などを使用します。ユーザーは、物件を閲覧し、不動産ブローカーにオンラインで連絡できます。

では、パッケージ化に集中しましょう。DreamHouse LWC ソースコードと、すでに作成した Salesforce DX プロジェクトファイルを取得します。この例では 1 つのパッケージを使用しますが、Salesforce DX プロジェクトは複数のパッケージを確保できます。ディレクトリ構造に基づいて異なるパッケージを分離できますが、コンポーネントは合理的な場所で共有してください。

このアプリケーションのパッケージを作成すると、開発ライフサイクルを通じて反復するときに、スクラッチ組織、UAT Sandbox、本番組織に簡単にパッケージをインストールできます。

パッケージ開発向けに特化して設計されたツールを使用するプロセス全体を説明します。

DreamHouse Lightning Web コンポーネント (LWC) アプリケーションのソースコードを取得しましょう。

コマンドウィンドウで、ソースコードを配置するディレクトリに変更して、このコマンドを実行します。

git clone https://github.com/dreamhouseapp/dreamhouse-lwc.git

git clone コマンドによって Salesforce DX プロジェクトの構造を使用した dreamhouse-lwc フォルダーが作成されます。この構造には DX プロジェクトファイルとスクラッチ組織定義ファイルが含まれています。DreamHouse LWC リポジトリは継続的に更新されるため、プロジェクトのバージョンが少し違っても、心配は要りません。

Finder や Windows エクスプローラーなどで開いた場合の dreamhouse-sfdx ディレクトリ構造全体を表示しています。

パッケージの設定

Trailhead Playground は Dev Hub 組織でもあります。パッケージを作成するには、まず Dev Hub 組織に対して認証を行い、ログインする必要があります。
```
sf org login web --set-default-dev-hub --alias DevHub
```

コマンドウィンドウで、Dev Hub 組織が接続されていることを再確認しましょう。
sf org list このコマンドの出力は、Dev Hub、Trailhead Playground、スクラッチ組織を含む、接続されているすべての組織を挙げます。(D) は、デフォルトの Dev Hub 組織を示します。

=== Orgs
     ALIAS       USERNAME                             ORG ID              CONNECTED STATUS
───  ──────────  ───────────────────────────────      ──────────────────  ────────────────
(D)  DevHub      myDevHub@example.com                 00DB0000000Ige5MAC  Connected
     MyTP        myName@mindful-raccoon-8184t4.com    00D6A000000fH8CUAU  Connected
     TestingOrg  name@example.com                     00D4x000006sFonEAE  Connected
ALIAS            USERNAME                             ORG ID              EXPIRATION  DATE
────────         ───────────────────                  ──────────────────  ────────────────
Scratch1         test@example.com                     00DZ000000N8ItoMAF  2021-02-24

コンピューターの dreamhouse-lwc ディレクトリに変更します。
任意のテキストエディターで sfdx-project.json を開き、sourceApiVersion バージョンをメモしておきます。
DreamHouse LWC はオープンソースプロジェクトで、多くの人々が作成に関与します。この Challenge を確実に完了させるために、sfdx-project.json ファイルの内容を次のコードで置き換えます。
```
{
   "packageDirectories": [
      {
         "path": "force-app",
         "default": true
      }
   ],
   "namespace": "",
   "sfdcLoginUrl": "https://login.salesforce.com",
   "sourceApiVersion": "61.0"
}
```
コードスニペットの sourceApiVersion 番号が元のファイルでメモしたバージョン番号と一致することを確認します。一致しない場合は、sourceApiVersion 番号を更新します。

この例で名前空間を使用しない理由

パッケージ名前空間はロック解除済みパッケージの場合省略可能ですが、パッケージ名前空間を含めることで、パッケージコンポーネントの整理の維持に役立ちます。ただし、名前空間にはいくつか追加の設定と事前の計画が必要であるため、この単元では扱いません。

スープのメタデータをロック解除済みパッケージに移行する場合は、名前空間なしでロック解除済みパッケージを作成します。この方法では、メタデータが未パッケージ状態からロック解除済みパッケージに移行したとき、メタデータ要素の API 名は変更されません。

パッケージの作成

GitHub から DreamHouse LWC アプリケーションをコピーしたとき、すべてのソースファイルをプロジェクトディレクトリに取得しました。これで、ベースパッケージを作成できます。

このセクションでは、DreamHouse LWC サンプルリポジトリを使用したパッケージ作成のワークフローを扱います。

ターミナルプロンプトまたはコマンドプロンプトで、dreamhouse-lwc ディレクトリに変更します。
名前空間なしでロック解除済みパッケージを作成し、デフォルトとして設定されていなければ、Dev Hub 組織に別名またはユーザー名を提示します。
```
sf package create --name dreamhouse --description "My Package" --package-type Unlocked --path force-app --no-namespace --target-dev-hub DevHub
```

--name は、パッケージ名です。この名前は別名で、後続のパッケージ化コマンドを実行するときに使用できます。
--path は、パッケージのコンテンツが含まれるディレクトリです。
--packagetype は、作成しているパッケージの種類を示します (この場合はロック解除済み)。

sfdx-project.json を開きます。これで、packageDirectories に、定義したパッケージ名が表示されますが、バージョン名とバージョン番号はプレースホルダーになっています。また、このコマンドによって packageAliases セクションが作成され、パッケージ名 (別名) がその関連するパッケージ ID (0Ho) に対応付けられます。
```
{
   "packageDirectories": [
      {
         "path": "force-app",
         "default": true,
         "package": "dreamhouse",
         "versionName": "ver 0.1",
         "versionNumber": "0.1.0.NEXT"
      }
   ],
   "namespace": "",
   "sfdcLoginUrl": "https://login.salesforce.com",
   "sourceApiVersion": "61.0",
   "packageAliases": {
      "dreamhouse": "0Hoxxx"
   }
}
```

パッケージの別名またはパッケージ ID を忘れても、sf package list を実行すれば、Dev Hub に関連付けられたすべてのパッケージをリストできます。

パッケージバージョンをテストするスクラッチ組織の作成

スクラッチ組織を作成しましょう。MyScratchOrg という別名を使用して、そこにロック解除済みパッケージをインストールします。スクラッチ組織でテストすれば、パッケージ化開発ライフサイクルの単体テストフェーズを簡便に実行できます。

sf org create scratch --definition-file config/project-scratch-def.json --duration-days 30 --alias MyScratchOrg --target-dev-hub DevHub

このコマンドはデフォルトのスクラッチ組織定義ファイルを使用します。これは、Trailhead Playground と同じエディションである Developer Edition のスクラッチ組織を作成します。期間は 30 日に設定し、開発の作業を完了 (またはこの Trailhead モジュールを完了) するために十分な時間を用意します。

パッケージバージョンの作成とスクラッチ組織へのインストール

パッケージをリリースする準備ができたら、パッケージバージョンと呼ばれるスナップショットを作成します。パッケージバージョンのインストールは、メタデータのリリースと同様です。パッケージバージョンは、一度作成されると、特定のメタデータセットを含む不変のアイテムとして機能します。

任意のテキストエディターで sfdx-project.json を開き、パッケージバージョンオプションを更新します。

versionName を Version 1.0 に、versionNumber を 1.0.0.NEXT に変更します。force-app ディレクトリは、デフォルト (かつ、唯一の) パッケージディレクトリです。このため、そこに含まれるすべてのソースはパッケージに含まれます。更新すると、sfdx-project.json ファイルは次のようになります。

{
   "packageDirectories": [
      {
         "path": "force-app",
         "default": true,
         "package": "dreamhouse",
         "versionName": "Version 1.0",
         "versionNumber": "1.0.0.NEXT"
      }
   ],
   "namespace": "",
   "sfdcLoginUrl": "https://login.salesforce.com",
   "sourceApiVersion": "61.0",
   "packageAliases": {
      "dreamhouse": "0Hoxxx"
   }
}

sfdx-project.json ファイルを保存します。
dreamhouse-lwc ディレクトリでパッケージバージョンを作成します。これは、メタデータをパッケージに関連付けます。
パッケージを本番組織にインストールするためには、ロック解除済みパッケージの Apex コードが 75% 以上というコードカバー率要件を満たす必要があります。この例ではコードカバー率を計算していません。このサンプルの Dreamhouse LWC リポジトリが Apex テストカバー率を十分に満たしていないことがわかっているためです。
```
sf package version create --package dreamhouse --installation-key test1234 --wait 10 --target-dev-hub DevHub
```

-p は、パッケージ ID に対応付けられるパッケージの別名です。
-d は、パッケージのコンテンツが含まれるディレクトリです。
-k は、不正にインストールされないようにパッケージを保護するインストールキーです。

パッケージバージョン作成プロセスは、通常数分かかります。状況メッセージが表示されるので、現在の状態を確認できます。パッケージバージョンの作成が完了すると、次のメッセージが表示されます。
```
Successfully created the package version [08cxxx]. Subscriber Package Version Id: 04txxx.
Package Installation URL: https://login.salesforce.com/packaging/installPackage.apexp?p0=04txxx
As an alternative, you can use the "sf package install" command.
```
sfdx-project.json の packageAliases セクションに新しいエントリがあります。
```
"packageAliases": {
   "dreamhouse": "0Hoxxx",
   "dreamhouse@1.0.0-1": "04txxx"
}
```
パッケージバージョンの別名を使用して、先ほど作成したスクラッチ組織にパッケージバージョンをインストールします。
```
sf package install --wait 10 --publish-wait 10 --package dreamhouse@1.0.0-1 --installation-key test1234 --no-prompt --target-org MyScratchOrg 
```
新しく作成したパッケージバージョンがスクラッチ組織で使用できるようになるまでに、数分かかることがあります。パッケージバージョンが使用可能になると、インストールが開始します。パッケージのインストールが完了すると、次のメッセージが表示されます。Successfully installed package [04t3XXX] (パッケージ [04t3XXX] が正常にインストールされました)
パッケージをインストールしたら、スクラッチ組織を開いて、パッケージを表示します。
```
sf org open --target-org MyScratchOrg
```
[Setup (設定)] から、[Quick Find (クイック検索)] ボックスに「Installed Packages」(インストール済みパッケージ) と入力し、[Installed Packages (インストール済みパッケージ)] を選択します。これはロック解除済みパッケージであるため、スクラッチ組織で直接変更して、更新されたメタデータを取得して、新しいパッケージバージョンを作成できます。ここでは、DreamHouse LWC アプリケーションにはすでに必要な要素がそろっているため、先に進んで、パッケージをリリースします。

パッケージバージョンのリリース

まだ説明していない機能に、パッケージ状態があります。パッケージは、最初に作成したときはベータ状態です。ベータパッケージは本番組織にインストールできません。これは、リリースするパッケージバージョンが本番用に準備完了であることを保証するための予防策です。バージョンの公開準備が完了したら、パッケージバージョンをリリース済みに昇格できます。

この単元で使用している Dreamhouse LWC サンプルリポジトリは変化しているため、Apex テストが 75% というコードカバー率要件を十分に満たすとは限りません。そのため、昇格をスキップして、作成したベータパッケージバージョンを引き続き使用します。

パッケージバージョン昇格コマンドは次のようになります。ただし、現時点でこのコマンドを実行しようとするとエラーメッセージが表示されます。

sf package version promote --package dreamhouse@1.0.0-1 --target-dev-hub DevHub

組織へのパッケージバージョンのインストール

重要な点ですが、最後に、パッケージバージョンを組織にインストールします。ベータパッケージバージョンは、スクラッチ組織、Sandbox、Trailhead Playground (DE 組織) にインストールできます。リリース済みパッケージバージョンは、すべての組織にインストールできます。このフェーズでは Sandbox にパッケージバージョンをインストールするのが一般的ですが、この演習では Trailhead Playground にパッケージをインストールします。

Trailhead Playground にパッケージバージョンをインストールするには、まずパッケージバージョンを承認された組織のリストに追加する必要があります。
```
sf org login web --alias MyTP
```
Trailhead Playground 用の別名を作成することをお勧めします。この例では MyTP です。組織にログインすると、CLI がログイン情報を記憶します。以降のコマンド発行時に必要となるのは、組織の別名を覚えておくことのみです。Trailhead Playground のユーザー名とパスワードがわからない場合は、「Trailhead Playground のユーザー名とパスワードの取得」を参照してください。

Trailhead Playground にパッケージバージョンをインストールします。

sf package install --wait 10 --publish-wait 10 --package dreamhouse@1.0.0-1 --installation-key test1234 --no-prompt --target-org MyTP

Trailhead Playground を開きます。
```
sf org open --target-org MyTP
```
Trailhead Playground で、[設定] から、[クイック検索] ボックスに「インストール済みパッケージ」と入力し、[インストール済みパッケージ] を選択します。また、ロック解除済みパッケージを正常にインストールしたことを確認するメールが送信されます。
[dreamhouse] をクリックして、[View Components (コンポーネントを表示)] をクリックします。
アプリケーションランチャーから [DreamHouse] アプリケーションを見つけて選択し、機能をいくつか確認します。

ヘルプをお探しですか?

もっと探す