ドキュメント›Edge Functions›Test and deploy from CI CI からのテストとデプロイ
最初の編集から自動デプロイメントまでの実行可能なループ。ローカル エミュレーションの制限が事前に規定されています。
8 分 読み取り·レベル 中間·2026/10/12 に改訂
この英語のテキストはフランス語のオリジナルから自動的に生成されたもので、まだレビューされていません。
このページは自動翻訳されました。英語版が正式です。
aura functions serve は、Deno を使用してファイルを実行し、保存時にファイルを再起動します。
terminalbash
aura functions serve hello --port 54321
curl -X POST http://127.0.0.1:54321/ -H 'Content-Type: application/json' -d '{"name":"Ada"}'
これはプレーンな Deno サーバーです。プラットフォームと比較すると、次のような特徴があります。
- プラットフォーム ヘッダーはありません。
x-aura-role および x-aura-user-id は存在しません。認可ブランチをテストするには、curl -H を使用して自分で送信してください。
- 秘密はありません。 それらをシェルに渡します:
STRIPE_SECRET_KEY=sk_test_… aura functions serve checkout。
- 制限はありません。 メモリ、タイムアウト、本体サイズ、レート制限は適用されません。
- 単純なリクエスト。 関数を直接呼び出すため、
path および method は、SDK の invoke オプションではなく、 curlの関数です。
invoke がプラットフォーム ルートを呼び出すため、SDK はこのサーバーをターゲットにすることができません。以下のように、実際のプロジェクトに対して SDK パスをテストします。
開発用のプロジェクトを作成し (最初の関数を参照)、そこに関数をデプロイし、SDK を通じてテストします。これには、プラットフォームの ID ヘッダー、制限、エラー クラスが含まれます。
tests/hello.test.tstypescript
import { createClient, FunctionsHttpError } from '@aurabase/aurabase-js'
import { describe, expect, it } from 'vitest'
const aura = createClient(process.env.AURA_TEST_URL!, process.env.AURA_TEST_ANON_KEY!)
describe('hello', () => {
it('greets', async () => {
const { data, error } = await aura.functions.invoke<{ greeting: string }>('hello', { body: { name: 'Ada' } })
expect(error).toBeNull()
expect(data?.greeting).toBe('Hello, Ada!')
})
it('reports a missing function as a FunctionsHttpError 404', async () => {
const { error } = await aura.functions.invoke('does-not-exist')
expect(error).toBeInstanceOf(FunctionsHttpError)
expect(error?.status).toBe(404)
})
it('refuses to list functions with a public key', async () => {
const { data, error } = await aura.functions.list()
expect(data).toBeNull()
expect(error?.status).toBe(403)
})
})
ヒント:
- 本番環境ではなく専用のプロジェクトを使用し、そのキーを CI シークレットに保管してください。
- 呼び出しレート制限は 15 呼び出しで、IP ごとに 1 秒あたり 1 呼び出しです。テストの間隔を空けるか、連続して実行します。
aura CLI は、macOS Apple Silicon では npm からインストールされ、他の場所ではソースからインストールされるため、HTTP API を使用すると Linux CI ジョブが簡単になります。デプロイは関数ごとに 1 つの POST であり、service_role キーで認証されます。この正確なループは実際のプロジェクトに対して実行され、その後関数が応答しました。
.github/workflows/deploy-functions.ymlyaml
name: Deploy functions
on:
push:
branches: [main]
paths: ['aurabase/functions/**']
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Deploy every function
env:
AURA_PROJECT_URL: ${{ secrets.AURA_PROJECT_URL }}
AURA_SERVICE_ROLE_KEY: ${{ secrets.AURA_SERVICE_ROLE_KEY }}
run: |
set -euo pipefail
for dir in aurabase/functions/*/; do
name=$(basename "$dir")
file="${dir}index.ts"
[ -f "$file" ] || continue
jq -n --arg name "$name" --rawfile code "$file" \
'{name: $name, runtime: "deno", code: $code}' |
curl -sS --fail-with-body -X POST "$AURA_PROJECT_URL/v1/functions" \
-H "apikey: $AURA_SERVICE_ROLE_KEY" \
-H "Content-Type: application/json" \
--data-binary @-
echo " deployed $name"
done
プッシュするたびにこれを安全に実行できるという事実:
- 本体には
env_varsがないため、 POST は既存の関数のコードを置き換え、その秘密を保持します。
- 関数は単一ファイルです。相対インポートは出荷されません。ローカルモジュールを使用する場合は、最初にバンドルしてください。
- サーバー上にバージョン履歴はありません。 Git 履歴はロールバックです。元に戻すには、コミットを元に戻し、CI を再度デプロイします。
次に、次のジョブで、デプロイしたばかりのプロジェクトに対して統合テストを実行します。
#環境
4. 開発、ステージング、およびプロダクション
1 つのプロジェクトが 1 つの環境です。環境ごとに 1 つのプロジェクトを作成し、それぞれに独自の URL とキーを設定し、CI にターゲットを選択させます。
| 環境 | プロジェクト | 導入時期 |
|---|
| 開発 | 開発者ごとに 1 つ、または共有 | オンデマンド、支店から |
| ステージング | my-app-staging | main にプッシュするたびに |
| 生産 | my-app | ステージング テストに合格した後のリリース タグ |
AURA_PROJECT_URL と AURA_SERVICE_ROLE_KEY を GitHub 環境ごとに保存し、各プロジェクトで各関数のシークレットを個別に設定します。プロジェクト間では何も共有されません。