ストリーミングはほとんどのブラウザと
Developerアプリで視聴できます。
-
cktoolと宣言型スキーマによるCloudKitテストの自動化
CloudKitコンテナのテストがかつてないほど簡単になりました。CloudKitの設定を迅速に行うことのできるコマンドラインユーティリティであるcktoolと、コンテナのプロトタイプと展開を迅速に行うことができる新しいスキーマ言語を紹介します。また、これらのツールを組み合わせて、Xcodeでテストを実行する前にコンテナを設定する方法も紹介します。 このセッションを最大限に活かしていただくためには、CloudKitとその開発環境および本番環境に精通し、レコードとデータタイプの基礎を理解していることが推奨されます。
リソース
関連ビデオ
WWDC22
WWDC21
-
ダウンロード
こんにちは Rustyです 私はCloudKit チームの エンジニアで 新しい CloudKit の 開発者ツールと スキーマ言語の 紹介を楽しみにしています このセッションでは まず クラウドと統合する アプリケーションの 統合テストが難しい理由を 説明します 次に CloudKit 用の新しい コマンドライン開発者ツール cktool のデモを行います cktool の使用方法は Xcode の中で テスト設定の自動化方法を 確認してください CloudKit の新しい 宣言型スキーマ言語を 次のステップでまとめます では 始めましょう
クラウドサービス依存の Appを作成する際 Appとサービス間で 明確な契約があります 統合テストは サービスの操作方法を 検証するのに役立ちますが 統合テストのセットアップを 適切に自動化するのは 難しい場合があります Appが使用する データモデルで サーバを最新に保つのは 簡単ではありません App開発中に スキーマを反復処理するとき サーバ上のスキーマと 使用しているスキーマが 正確に一致することが 重要です また テスト実行のたびに クラウド内の サンプルデータに対して 実行の有無を確認するのは 難しい場合があります 特に テストデータの一部が 変更された場合は 困難です 私たちのチームは 全てをより簡単にしました 最新のCloudKitスキーマ言語を 使うと CloudKit スキーマを Appコードと共に ファイルで宣言し バージョン管理でチェックし プロジェクト内の 全ての変更を 追跡できるようになります Appのデータモデルと CloudKit スキーマの 一致を確認してください 新しいcktoolコマンドライン 開発者ツールを使用すると CloudKit サーバへ スキーマ宣言を送信する プロセスは 簡単に自動化できます また テスト実行の直前に サーバ上に サンプルデータと同じ セットも作成できます
では cktoolを 使い始めましょう 初めに Xcode 13を インストールします そうすれば すぐにcktoolを 使い始めることが出来ます cktoolはxcrunで起動され いくつかコマンドがあります 例えば CloudKit サーバでの レコードの作成 サーバ内にある レコードの照会 スキーマ言語ファイルの インポートとエクスポート ツール自体の承認管理などを 行うことができます cktoolを使う前に CloudKit での承認について いくつか理解する必要が あります cktool は CloudKit サーバと 直接通信するために 最初にツールを承認する 必要があります スキーマのインポートなど コンテナ管理機能の実行に cktool のみ許可するか データへアクセスするために 追加で許可するか 選べます CloudKit はこのために 新たに2つ考えました 1つ目は「管理トークン」 と呼ばれ cktoolでCloudKitコンテナを 管理するため使用されます これは 1 つの 開発者アカウントに 関連付けられており 開発者が複数の場合は チーム間で使用でき スキーマのインポートや エクスポートなど 構成する場合だけで コンテナ内データへの アクセス権はありません このため2つめの 「ユーザートークン」を 導入し これを使って Appのコンテナにある ユーザーデータベースか 共有データベースに データを書き込めます 2つのトークンを CloudKit コンソールから 取得できます CloudKitコンソールの詳細は WWDC21 セッション 「CloudKitコンソールについて」 を確認してください 開発者アカウントの 管理トークンと ユーザートークンの両方を 取得したので これらをツールに追加して macOS キーチェーンに 安全に保存でき 次に進む準備ができました これで面白いことが 出来るようになりました 例えば Apple Developer の チームメンバーの リストを依頼すると 所属するチームのリストが 表示されます 最高でしょ コンテナにデータベースの スキーマ定義があり 変更を行う前に ソースコードリポジトリに データベーススキーマを コミットしたいとします cktool を使えば簡単です export-schema コマンドを 使用すると 開発スキーマを schema.ckdb ファイルに プルダウンできます このファイルは前述した CloudKit スキーマ言語で フォーマットされています では このファイルについて 詳しく説明します cktool はコンテナに データ追加もできます このサンプルブックレコード のように JSON として表現された サンプル値がある場合 ツールへの入力として 共有データベースに レコードを作成できます ツール動作の基本的な意味が 理解できたので 3 ステップの簡単な スクリプトを作成し AppのCloudKit コンテナ 開発環境から すべてのデータを削除し スキーマ宣言を サーバに送信して テストデータをロードします このように Xcode で このスクリプトを 事前動作確認の 一部として実行し そのたびに Appが使用する スキーマが正確で CloudKitコンテナが常に 一致した状態を確認できます Xcode では プロジェクトのAppの スキームを編集し 動作確認フェーズで プリアクションを選択し 新しい実行スクリプトを 追加できます Appターゲットの ビルド設定を提供し スクリプトが スキーマファイルへの パスを持つようにします cktool コマンドを貼付けて コンテナをリセットし プロジェクトのファイルから スキーマをインポートし 最後にコンテナの 共有データベースに サンプルレコードを作ります これらのコマンドは 同期されているので 次々に実行されます 期待通りにいかない場合は 全ての実行が停止されるので 注意してください そのような場合 動作確認を実行する前に 予備テストで 問題解決するようにします それだけです Xcode 動作確認を実行すると cktool は CloudKit コンテナを 実行する直前に準備します 完璧でしょ Appのデータモデルの 変更が必要な場合は どうすればよいでしょうか? CloudKit スキーマ言語を 詳しく説明していきます 実際 調べてみましょう 以前にダウンロードした ckdbファイルです 中にCloudKit スキーマ言語 の新しいものがあります レコードタイプを記述する 効果的な方法です 読み書きが簡単で Appを使いプロジェクトに 含めることができます スキーマセクション内に レコードタイプがあり これを正確に反映し CloudKitコンソールの コンテナに表示されます 各レコードタイプには 複数のフィールドがあり それぞれに名前と データタイプがあります 三重下線フィールドの名前は システムフィールドです CloudKit により全ての レコードタイプに作成され これらのフィールドの 下には CloudKit レコードタイプの カスタムAppデータを表す フィールドがあります CloudKitコンソールで 実行できるように クエリで 並び変え可能な フィールドのインデックスを 作成できます CloudKit スキーマ言語で これを行うには フィールドのデータ型の 直後に インデックスを宣言します このブックレコードタイプの カスタムフィールド 「title」のようになります セキュリティロールが フィールドの下に 表示されます システムに組み込まれた 3つのセキュリティロール 同様に セキュリティロールごとに 名前を付ける権限を 付与できます 「Creator」は レコード作成のユーザーのみ 「World」は全ユーザー 「iCloud」は認証された ユーザーが含まれます CloudKit スキーマ言語では 単一行でも複数行でも コメントを入れることができ スキーマファイルを より読みやすく することができます ファイル処理でコメントは CloudKit サーバに 無視されるため コメントを任意の場所に 自由に入力できます CloudKit スキーマ言語により 開発者はスキーマを 迅速かつ柔軟に 変更できるようになりました CloudKit スキーマの 進化について いくつかの核となる概念を 覚えておくことが重要です コンテナの開発環境では レコードタイプを 完全に制御できます 開発中のレコードタイプを 追加・削除したり レコードタイプ内の カスタムフィールドを 追加・削除することができ 制限はありません 新しいレコードタイプは 開発環境に移行でき 新しいフィールドは 既存のレコードタイプにも 追加できます ただし レコードタイプを コンテナの本番環境に 一度移動すると 削除や名前変更はできません 本番環境に移動された レコードタイプ内の カスタムフィールドも 同様です 理由は CloudKit サーバが レコードタイプとフィールド 2つを認識して 旧バージョンのAppで 使用される可能性が あるからです つまりコンテナの開発環境で スキーマ宣言に破壊的変更を 加えることはできますが これらの破壊的変更を 本番環境に反映させることは できません 本番環境でインデックスの 追加・削除は可能です セキュリティロールの設定も 変更できます スキーマ販売促進の概念は CloudKit では初めてでなく 新しいファイルベースの スキーマ宣言から 得られる柔軟性を確認し 理解することの 重要性を意味します cktool ができることと CloudKit スキーマ言語の 機能がわかったと思うので 両方 試してみることを お勧めします 管理とユーザートークンから CloudKit コンソールで cktoolを認証し コマンドを調べます 既存の CloudKit スキーマを 言語ファイルに エクスポートし プロジェクトに追加して バージョン管理に チェックインしてください cktool を使用し統合テストの セットアップ手順を いくつか作成し スクリプトの 事前動作確認をして Xcodeスキームに追加します コマンドラインから CloudKit コンテナを選択し 特定の要素を管理する機能は 実に有効です CloudKit スキーマの宣言を 他のAppコードと一緒に ファイルに保持することで 開発ライフサイクル 全体を通して データモデルとの 一貫性を保てます 統合テストのクラウド設定を 自動化し連結させることにも 優れています 新しいツールで何ができるか 確認してください CloudKit の詳細とWWDC21 に興味を持っていただき ありがとうございました [音楽]
-
-
3:27 - cktool: Save tokens, get teams
xcrun cktool save-token --type management xcrun cktool save-token --type user xcrun cktool get-teams
-
3:45 - cktool: Export schema
xcrun cktool export-schema \ --team-id XYZ1234567 \ --container-id iCloud.com.WWDC21.Example \ --environment development \ --output-file schema.ckdb
-
4:07 - cktool: Create record
xcrun cktool create-record \ --team-id XYZ1234567 \ --container-id iCloud.com.WWDC21.Example \ --environment development \ --database-type public \ --record-type Book \ --fields-json '{ "title": { "type": "stringType", "value": "Treasure Island" }, "pageCount": { "type": "int64Type", "value": 304 } }'
-
5:05 - cktool: Test pre-action script
xcrun cktool reset-schema \ --team-id XYZ1234567 \ --container-id iCloud.com.WWDC21.Example xcrun cktool import-schema \ --team-id XYZ1234567 \ --container-id iCloud.com.WWDC21.Example \ --environment development \ --file $PROJECT_DIR/Example/CloudKitSchema.ckdb xcrun cktool create-record \ --team-id XYZ1234567 \ --container-id iCloud.com.WWDC21.Example \ --environment development \ --database-type public \ --record-type Book \ --fields-json '{ "title": { "type": "stringType", "value": "Great Expectations" }, "pageCount": { "type": "int64Type", "value": 544 }, "description": { "type": "stringType", "value": "Depiction of the education of an orphan nicknamed Pip" }, "publishedOn": { "type": "timestampType", "value": "1860-12-01T03:23:07.415Z" }, "reviewStatus": { "type": "int64Type", "value": 1 } }'
-
5:51 - Schema language file: Example
DEFINE SCHEMA RECORD TYPE Book ( "___createTime" TIMESTAMP, "___createdBy" REFERENCE, "___etag" STRING, "___modTime" TIMESTAMP, "___modifiedBy" REFERENCE, "___recordID" REFERENCE QUERYABLE, description STRING, pageCount INT64, publishedOn TIMESTAMP, reviewStatus INT64, // A single-line comment, for humans title STRING QUERYABLE, GRANT WRITE TO "_creator", GRANT CREATE TO "_icloud", GRANT READ TO "_world" );
-
-
特定のトピックをお探しの場合は、上にトピックを入力すると、関連するトピックにすばやく移動できます。
クエリの送信中にエラーが発生しました。インターネット接続を確認して、もう一度お試しください。