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.
1. Führen Sie es lokal aus
aura functions serve führt Ihre Datei mit Deno aus und startet sie beim Speichern neu.
Es handelt sich um einen einfachen Deno-Server. Im Vergleich zur Plattform verfügt es über:
- Keine Plattform-Header.
x-aura-roleundx-aura-user-idfehlen: Senden Sie sie selbst mitcurl -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
pathundmethoddie Ihrercurlund nicht dieinvoke-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.
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.
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.
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.
Fakten, die dafür sorgen, dass es bei jedem Anstoß sicher läuft:
- Der
POSTersetzt den Code einer vorhandenen Funktion und behält seine Geheimnisse, da der Körper keinenenv_varshat. - 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.
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:
| Umwelt | Projekt | Wird wann bereitgestellt |
|---|---|---|
| Entwicklung | eine pro Entwickler oder geteilt | auf Anfrage, in einer Filiale |
| Inszenierung | my-app-staging | jeder Push auf main |
| Produktion | my-app | ein 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.