Aurabase-Logo
AurabasisDokumente
Dokumente›Edge Functions›Test and deploy from CI

Testen und Bereitstellen über CI

Eine praktikable Schleife von der ersten Bearbeitung bis zur automatischen Bereitstellung, wobei die Grenzen der lokalen Emulation im Voraus angegeben werden.

8 Min. gelesen·Ebene Mittelstufe·Überarbeitet am 12.10.2026
Dieser englische Text wurde automatisch aus dem französischen Original generiert und wurde noch nicht überprüft.
Diese Seite wurde automatisch übersetzt. Maßgeblich ist die englische Version.
#
Lokal

1. Führen Sie es lokal aus

aura functions serve führt Ihre Datei mit Deno aus und startet sie beim Speichern neu.

terminalbash
aura functions serve hello --port 54321
curl -X POST http://127.0.0.1:54321/ -H 'Content-Type: application/json' -d '{"name":"Ada"}'

Es handelt sich um einen einfachen Deno-Server. Im Vergleich zur Plattform verfügt es über:

  • Keine Plattform-Header. x-aura-role und x-aura-user-id fehlen: Senden Sie sie selbst mit curl -H, um Autorisierungszweige zu testen.
  • Keine Geheimnisse. Übergeben Sie sie in Ihrer Shell: STRIPE_SECRET_KEY=sk_test_… aura functions serve checkout.
  • Keine Grenzen. Speicher-, Timeout-, Körpergrößen- und Ratenbeschränkungen werden nicht angewendet.
  • Einfache Anfragen. Sie rufen die Funktion direkt auf, daher sind path und method die Ihrer curl und nicht die invoke-Optionen des SDK.

Das SDK kann diesen Server nicht als Ziel verwenden, da invoke die Plattformroute aufruft. Testen Sie den SDK-Pfad anhand eines realen Projekts, wie unten beschrieben.

#
Integration

2. Testen Sie es in der Realität

Erstellen Sie ein Projekt für die Entwicklung (siehe Ihre erste Funktion), stellen Sie die Funktion dort bereit und testen Sie sie über das SDK. Dies umfasst die Identitätsheader, Grenzwerte und Fehlerklassen der Plattform.

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)
  })
})

Tipps:

  • Verwenden Sie ein dediziertes Projekt, niemals eine Produktion, und bewahren Sie die Schlüssel in Ihren CI-Geheimnissen auf.
  • Die Aufrufratenbeschränkung beträgt 15 Anrufe, dann 1 pro Sekunde und IP. Platzieren Sie Ihre Tests oder führen Sie sie seriell aus.
#
CI

3. Bereitstellung über CI

Die aura-CLI wird von npm auf macOS Apple Silicon und von der Quelle anderswo installiert, sodass ein Linux-CI-Job mit der HTTP-API einfacher ist. Die Bereitstellung erfolgt mit einem POST pro Funktion, authentifiziert mit einem service_role-Schlüssel. Diese exakte Schleife wurde für ein reales Projekt ausgeführt und die Funktion wurde anschließend beantwortet.

.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

Fakten, die dafür sorgen, dass es bei jedem Anstoß sicher läuft:

  • Der POST ersetzt den Code einer vorhandenen Funktion und behält seine Geheimnisse, da der Körper keinen env_vars hat.
  • Eine Funktion ist eine Einzeldatei: Relative Importe werden nicht versendet. Wenn Sie lokale Module verwenden, bündeln Sie zuerst.
  • Es gibt keinen Versionsverlauf auf dem Server. Ihr Git-Verlauf ist das Rollback: Um zurückzugehen, machen Sie das Commit rückgängig und lassen Sie CI erneut bereitstellen.

Führen Sie dann in einem folgenden Job Ihre Integrationstests für das Projekt durch, das Sie gerade bereitgestellt haben.

#
Umgebungen

4. Entwicklung, Inszenierung und Produktion

Ein Projekt ist eine Umgebung. Erstellen Sie ein Projekt pro Umgebung, jedes mit seiner eigenen URL und seinen eigenen Schlüsseln, und lassen Sie CI das Ziel auswählen:

UmweltProjektWird wann bereitgestellt
Entwicklungeine pro Entwickler oder geteiltauf Anfrage, in einer Filiale
Inszenierungmy-app-stagingjeder Push auf main
Produktionmy-appein Release-Tag, nachdem die Staging-Tests bestanden wurden

Speichern Sie AURA_PROJECT_URL und AURA_SERVICE_ROLE_KEY pro GitHub-Umgebung und legen Sie die Geheimnisse jeder Funktion in jedem Projekt separat fest. Nichts wird zwischen Projekten geteilt.

Zuletzt aktualisiert · 12.10.2026