CI/CD パイプラインを設定する

Atlas App Services はサポート終了のステータスに達し、 MongoDBでアクティブにサポートされなくなりました。Atlas UIでは引き続き trigger を利用できます。詳細については、の廃止ページを参照してください。

Overview

多くの開発者は、継続的統合、配信、配置パイプラインを使用して、変更を行うたびにアプリケーションを自動的にテストおよび公開しています。これは、git のような共有バージョン管理システムを使用して、複数のユーザーがコードベースで並行して作業する大きなアプリに最も一般的であり、便利です。

このガイドでは、ほとんどの CI/CD パイプラインに一般的な高レベルのステージを説明し、各ステージで実行する操作について説明します。さらに、Atlas App Services アプリの構成およびテストのためにパイプライン内で実行可能な一般的なタスクとアクションのリストが含まれています。

Tip

Githubアクションで実際の例を見る

実際のアプリケーションのテスト、配置、およびその他のタスクを管理するサンプル CI/CD パイプラインについては、「開発者ハブでGithub アクションを使用して App Services アプリ用の CI/CD パイプラインを構築する方法MongoDB 」に関する記事をご覧ください。。

パイプラインステージ

高レベルでは、ほとんどのパイプラインが複数のステージを通過し、それぞれが異なる問題を処理するという共通のパターンを共有します。

開発

開発ステージは、アプリの新機能を作成したり、バグを修正したりするための最初のステップです。このステージでは、アプリケーションの構成ファイルとソースコードを操作して、必要な変更を実装します。

既存のアプリの新機能を開発するには

メインアプリをフォークし、新しい開発コピーを配置します。このインスタンスのアプリ ID は、本番アプリとは異なるものになります。また、環境値のテンプレートを使用して、開発データソースや本番にリンクされていないその他のサービスを使用することもできます。
アプリケーションを開発します。これには、クライアントアプリ画面のアップデートや追加、新しいデータベースtriggerの追加、またはその他のアプリケーション機能のアップデートや追加が含まれます。同期された Realm オブジェクトスキーマに変更を加える必要がある場合は、開発モードを使用できます。

自動テストをローカルで実行し、コードに新しいエラーが発生しないことを確認します。ローカルで渡すテストはアプリに統合バグがないことを保証するものではありませんが、変更に回帰や意図しない動作が含まれないという信頼性は高まります。

ステージング

ステージングステージは、QA（品質保証）、テスト、または事前本番環境と呼ばれることもありますが、可能な限り本番と同様の環境で開発の変更をシミュレートするステップです。これにより、レビューに使用可能なバージョンのアプリが提供され、本番データに影響を与えずにライブサービスとの統合バグを検出することができます。

ステージング配置の詳細は、アプリケーションのニーズによって異なります。ただし、次の高レベルの手順を使用して設定できます。

ステージング環境を設定します。 本番環境を可能な限りミラーリングした構成で、非本番のサービスとデータソースを別々に使用します。たとえば、 stagingという名前の Atlas クラスターを使用できます。このクラスターはproductionクラスターと同じ構成です。ユースケースに応じて、すべてのステージングビルドで再利用する一貫したアプリがある場合や、ステージングビルドごとに新しいアプリを作成する場合もあります。
既存のステージングビルドを作成または使用します。 新しいプルリクエストを作成する場合など、 CI/CD プロセスの一部としてステージングビルドを自動的に作成できます。ステージングビルドごとに新しいアプリを使用することも、ビルド間で共有する事前に構築された環境を再利用することもできます。
アプリが期待どおりに動作することを確認します。 これには、ステージング環境に対して自動テストスイートを実行するか、動作を手動でチェックするか、ユーザー受け入れテストを通じて承認を取得することが含まれる場合があります。

本番環境

本番環境ステージは、変更したアプリが本番環境に配置される最後の配置ステップです。理想的なのは、このステージですでに変更をローカルとステージングでテストして、デプロイできることを確認していることです。本番アプリをアップデートすることで、 CI/CD ワークフローの一部として手動または自動的に本番環境に配置できます。

ビルドタスク

このセクションでは、 CI/CD パイプラインで実行する一般的なタスクについて説明します。ユースケースやパイプラインのステージによっては、これらのタスクが必ずしもすべて実行されるとは限りませんが、一般的にほとんどのパイプラインではこれらすべてが少なくとも 1 回実行されます。

環境を構成する

アプリの構成とコードは通常、開発ステージ間で類似している必要があります。ただし、環境に応じて特定の構成オプションの値を変更する必要がある場合があります。

構築するステージを決定し、適切な構成値を設定します。たとえば、開発ステージで新しいアプリのアプリ ID を使用してアプリを構成することも、本番ステージで本番アプリ ID を使用することもできます。

# Use the production App ID for the main branch
export REALM_APP_ID="myapp-abcde"
# Use a staging App ID for the QA branch
export REALM_APP_ID="myapp-staging-fghij"
# Use a new App ID for development branches - you'll need to create the app first!
export REALM_APP_ID="myapp-dev-zyxwv"

Tip

アプリ ID の検索

アプリ ID は、必ずしもハードコードできない場合があります。 App Services CLI を使用して特定のアプリ ID を検索できます。例については、「アプリの作成」を参照してください。

App Services CLI を設定する

App Services CLI は、Atlas アプリをプログラムによって作成、構成、および管理する最も簡単な方法です。配置スクリプトには最新バージョンをインストールし、使用する必要があります。

App Services CLI は npm で利用できます。システムに CLI をインストールするには、Node.jsがインストールされていることを確認し、シェルで次のコマンドを実行します。

npm install -g atlas-app-services-cli

CLI を認証して使用するには、MongoDB Atlas の公開/プライベート API キーのペアも必要です。 API キーの取得方法について詳しくは、「プログラマティック API キー」を参照してください。

ログインするには、API キーを新しい名前付きプロファイル構成に保存し、そのプロファイルでログインします。

～/.config/appservices/"Profile<Profile Name> Name".YAML

<Profile Name>:
  public_api_key: "<MongoDB Atlas Public API Key>"
  private_api_key: "<MongoDB Atlas Private API Key>"
  atlas_base_url: "https://cloud.mongodb.com"
  realm_base_url: "https://services.cloud.mongodb.com"
  telemetry_mode: ""

appservices login --profile="<Profile Name>"

Tip

すべてのコマンドで--profileフラグを必ず使用してください。そうしないと、App Services CLI はユーザーがログインしていることを認識しません。

アプリを作成する

App Services CLI を使用して、開発とテストで使用する新しいアプリを作成できます。パイプラインが開発フェーズまたはステージングフェーズにある場合は、本番環境アプリ以外のアプリを使用して変更を配置およびテストする必要があります。

開発ブランチまたはステージングブランチに新しいアプリを使用するには:

新しいアプリを作成する
アプリの構成ファイルのブランチに基づいて新しいアプリをプッシュします。
```
cd path/to/realmApp
appservices push -y --project="<MongoDB Atlas Project ID>" # e.g. --project="609ea544934fe445460219a2"
```

アプリ ID の保存

新しいアプリには一意の App ID 値があります。この値は、パイプラインおよびクライアントアプリで識別するために必要になります。値は、環境変数、ファイル、または他の場所に保存する必要があります。

# Save to an environment variable
output=$(appservices app describe)
app_id=$(echo $output | sed 's/^.*client_app_id": "\([^"]*\).*/\1/')
export REALM_APP_ID=app_id
# Save to a file
echo $REALM_APP_ID > ./clients/ios/realm-app-id.txt

アプリの更新

App Services CLI を使用して、共有ステージングアプリや本番配置などの既存のアプリをアップデートできます。アプリはすでに存在するため、そのアプリ ID を検索できるはずです。

既存のアプリを更新するには、 --remoteフラグでそのアプリ ID を指定します。

appservices push --remote=$REALM_APP_ID -y

アプリに対してテストを実行

アプリには、すべてが動作することを確認するために実行できる自動ユニットと統合テストスイートが含まれている必要があります。テスト設定の詳細はアプリによって異なりますが、さまざまなシミュレーターを使用して複数のプラットフォームでテストを実行する必要がある場合があります。

統合テストがある場合は、以前のリリースをチェックし、アプリの現在のバージョンに対して統合テストを実行して、下位互換性を確保できます。

ジョブをクリーンアップする

CI/CD ステージまたはパイプラインの最後に、そのテスト専用に作成したリソースをクリーンアップする必要がある場合があります。たとえば、新しい開発アプリまたはステージングアプリを作成した場合、変更がマージされると、それらに関連付けられているアプリやデータベースを削除する可能性があります。あるいは、本番アプリまたは永続的なステージングアプリを使用している場合は、クリーンアップをしたくない場合もあります。

クリーンアップを行う前に、どのリソースが将来役立つ可能性があるかを考慮してください。たとえば、テストが失敗した場合、アプリとそのデータベースの削除をスキップすることもできます。そうすれば、問題を手動で調査し、障害の原因となったアプリ設定やデータを見つけることができます。

戻る

アプリ環境を構成する

配置モデルの変更