Automatisierte API-Tests in Bamboo CI ausführen: Schritt-für-Schritt-Anleitung

Ihr Build ist grün. Unit-Tests sind erfolgreich, die JAR-Datei ist gepackt, das Artefakt wurde bereitgestellt. Dann erreicht die erste echte Anfrage die Staging-API und ein nachgeschalteter Dienst gibt einen 500er-Fehler zurück, weil jemand vor zwei Commits ein Antwortfeld geändert hat. Der Build sagte, alles sei in Ordnung. Das war es nicht. Er hat einfach nie die API überprüft.

Dies ist die Lücke, die die meisten Bamboo CI-Pipelines aufweisen. Atlassian Bamboo ist gut darin, Code zu kompilieren, JUnit-Suiten auszuführen und Artefakte zu versenden. Was es nicht von sich aus tut, ist zu überprüfen, ob Ihre HTTP-Endpunkte immer noch so funktionieren, wie Ihr Vertrag es verspricht. Wenn Sie dieses Sicherheitsnetz wünschen, müssen Sie automatisierte API-Tests als Phase in der Pipeline hinzufügen. Dieser Leitfaden zeigt Ihnen genau, wie das geht, indem Sie Apidog verwenden, um die Tests zu erstellen, und die Apidog CLI, um sie in einem Bamboo-Job auszuführen.

Am Ende verfügen Sie über einen Bamboo-Plan, der bei jedem Push Ihre Endpunkte aufruft, Statuscodes überprüft, Antworttexte anhand Ihres Schemas validiert und den Build fehlschlagen lässt, sobald ein Vertrag bricht. Keine Postman-Lizenz pro Arbeitsplatz, keine manuell geschriebenen Assertions-Skripte zum Warten und ein echter HTML-Testbericht, der jedem Build beigefügt ist. Laden Sie Apidog herunter, wenn Sie mitmachen möchten; das CLI-Tool ist kostenlos und quelloffen.

Warum API-Tests in Bamboo gehören, nicht danach

Viele Teams testen ihre APIs manuell, oder schlimmer noch, in der Produktion. Jemand klickt vor einer Veröffentlichung eine Sammlung gespeicherter Anfragen durch und prüft die Antworten visuell. Das funktioniert, bis es nicht mehr funktioniert. Leute vergessen. Veröffentlichungen finden an einem Freitag statt. Der eine Endpunkt, den niemand erneut überprüft hat, ist derjenige, der kaputtgeht.

CI existiert, um diese menschliche Variable zu eliminieren. Der ganze Sinn eines Build-Servers besteht darin, dass dieselben Prüfungen jedes Mal auf die gleiche Weise, automatisch und ohne dass jemand daran denken muss, sie auszuführen, ablaufen. Ihre Unit-Tests sind bereits dort. Ihre Integrationstests wahrscheinlich auch. API-Tests verdienen die gleiche Behandlung, und das aus einigen konkreten Gründen:

• Verträge brechen stillschweigend. Ein Backend-Entwickler benennt ein JSON-Feld von userId in user_id um. Unit-Tests bestehen weiterhin, da sie die Funktion testen, nicht das Wire-Format. Das mobile Team findet es drei Tage später heraus. Ein API-Test, der den Antworttext überprüft, fängt dies im selben Build ab, der es eingeführt hat.
• Statuscodes lügen, wenn niemand zuschaut. Ein Endpunkt, der 201 Created zurückgeben sollte, gibt nach einer Refaktorierung 200 OK zurück. Funktionell ähnlich, technisch falsch, und ein strenger Client wird es ablehnen. Eine Pipeline-Assertion markiert dies in Sekunden.
• Auth-Regressionen sind teuer. Ein falsch konfigurierter Token-Refresh-Flow, der bei gültigen Anmeldeinformationen 401 zurückgibt, ist die Art von Fehler, die einen Anmeldebildschirm lahmlegt. Das Ausführen einer authentifizierten Anfrage bei jedem Build bedeutet, dass Sie es finden, bevor Ihre Benutzer es tun.
• Umgebungen driften. Staging erhält eine Konfigurationsänderung, ein Feature-Flag wird umgeschaltet, eine Abhängigkeit wird aktualisiert. Das Ausführen derselben API-Suite gegen Staging nach jedem Deploy sagt Ihnen sofort, ob die Umgebung noch intakt ist.

Der tiefere Kontext ist derselbe Grund, warum Teams überhaupt CI/CD einführen: Probleme frühzeitig erkennen, wenn sie günstig zu beheben sind, anstatt spät, wenn sie teuer und peinlich sind. API-Tests sind nur die Schicht dieser Strategie, die die meisten Pipelines überspringen.

Wie API-Tests in einen Bamboo-Plan passen

Bevor wir Schritt für Schritt vorgehen, ist es hilfreich zu verstehen, wo dies im Bamboo-Modell angesiedelt ist. Bamboo organisiert die Arbeit in Plänen, und jeder Plan enthält eine oder mehrere Phasen, die der Reihe nach ausgeführt werden. Jede Phase enthält Jobs, und jeder Job ist eine Abfolge von Aufgaben. Aufgaben sind die eigentlichen Befehle: Checkout, Kompilieren, Skript ausführen.

Ihre API-Tests werden zu einer Aufgabe innerhalb eines Jobs innerhalb einer Phase. Die natürliche Platzierung ist eine dedizierte Phase, die nach dem Build und der Bereitstellung Ihrer Anwendung in einer Testumgebung ausgeführt wird, da Sie etwas Aktives benötigen, an das Sie Anfragen senden können. Ein typischer Plan sieht am Ende so aus:

Plan: payments-service
├── Stage: Build
│   └── Job: Compile & Unit Test
│       ├── Task: Source Code Checkout
│       └── Task: Maven, clean package
├── Stage: Deploy to Staging
│   └── Job: Deploy
│       └── Task: Deploy artifact to staging
└── Stage: API Tests          <- Das fügen Sie hinzu
    └── Job: Run API Suite
        ├── Task: Source Code Checkout
        ├── Task: Script, install & run Apidog CLI
        └── Task: Final, publish test report

Wenn eine Aufgabe in der API-Testphase mit einem von Null verschiedenen Code beendet wird, kennzeichnet Bamboo die Phase als fehlgeschlagen und den gesamten Build als rot. Das ist genau das Verhalten, das Sie wünschen; ein gebrochener Vertrag sollte die Linie stoppen, nicht durchrutschen.

Das Tool, das die eigentliche Arbeit in dieser Skriptaufgabe erledigt, ist die Apidog CLI, ein Befehlszeilen-Runner, der Testszenarien ausführt, die Sie visuell in Apidog entwerfen. Sie erstellen den Test einmal, in einer GUI, ohne Code, und derselbe Test läuft unverändert in Ihrem Terminal und in Bamboo. Dies ist das gleiche Muster, das Teams verwenden, um API-Tests in jedem CI/CD-System zu automatisieren; Bamboo ist ein Ziel unter vielen.

Schritt 1: Erstellen Sie Ihre API-Tests in Apidog

Sie können keine Tests in CI ausführen, bevor Sie Tests haben. Apidog ist der Ort, an dem Sie sie entwerfen, und das Design ist visuell, sodass ein QA-Ingenieur, der keinen Code schreibt, dieselbe Suite erstellen kann wie ein Backend-Entwickler.

Öffnen Sie Apidog und erstellen Sie ein Testszenario. Ein Szenario ist eine geordnete Abfolge von API-Anfragen, die von oben nach unten ausgeführt werden, wobei jeder Schritt Daten aus den vorhergehenden Schritten wiederverwenden kann. Ein realistisches Szenario für einen Zahlungsdienst könnte sein:

1. POST /auth/login mit gültigen Anmeldeinformationen, dann das Bearer-Token aus der Antwort extrahieren.
2. POST /orders unter Verwendung dieses Tokens, Erstellen einer neuen Bestellung, dann die zurückgegebene orderId speichern.
3. GET /orders/{orderId} und bestätigen, dass die Bestellung mit dem richtigen Status angezeigt wird.
4. DELETE /orders/{orderId} zur Bereinigung.

Fügen Sie für jede Anfrage Assertions hinzu. Dies ist der Teil, der eine Anfrage in einen Test verwandelt. Apidog ermöglicht Ihnen das visuelle Assertieren, ohne dass Skripte erforderlich sind:

• Statuscode gleich 200 (oder 201, je nachdem, was der Vertrag besagt).
• Ein JSON-Feld existiert und stimmt überein: $.data.status ist gleich "pending".
• Die Antwort validiert sich gegen das OpenAPI-Schema des Endpunkts, sodass jeder unerwartete Feldtyp oder fehlende erforderliche Eigenschaft den Schritt fehlschlagen lässt.
• Die Antwortzeit bleibt unter einem Schwellenwert, z.B. 800 ms, sodass auch eine langsame Regression auffällt.

Schema-basierte Assertions sind erwähnenswert. Da Apidog Schema-First ist, kennt es bereits die Form, die Ihr Endpunkt in seiner API-Definition versprochen hat. Sie können mit einem Klick „diese Antwort stimmt mit ihrem Schema überein“ behaupten, und diese einzelne Prüfung schützt vor einer ganzen Kategorie von Vertragsabweichungen, umbenannten Feldern, falschen Typen, gelöschten Eigenschaften, ohne dass Sie eine einzige Zeile schreiben müssen. Wenn Sie von einem Skript-lastigen Tool kommen, beseitigt dies allein viel Wartungsaufwand. Es ist dasselbe visuelle Assertions-Modell, das Apidog zu einer gängigen Postman-Alternative für API-Tests macht.

Gruppieren Sie verwandte Szenarien in einer Testsuite, wenn Sie viele haben. Eine Suite ist lediglich eine Sammlung von Szenarien, die Sie zusammen ausführen können, was Ihren CI-Befehl einfach hält; Sie weisen den Runner auf eine Suite an, anstatt zwanzig Szenarien aufzulisten.

Verwenden Sie Umgebungsvariablen für alles, was sich zwischen Lokal, Staging und Produktion ändert: Basis-URLs, Anmeldeinformationen, API-Schlüssel. Definieren Sie eine Staging-Umgebung in Apidog mit baseUrl, die auf Ihren Staging-Host eingestellt ist. Sie werden der CLI zur Laufzeit mitteilen, welche Umgebung verwendet werden soll, sodass dasselbe Szenario in Bamboo gegen Staging und auf Ihrem Laptop gegen Localhost ausgeführt wird.

Schritt 2: Generieren Sie ein Apidog-Zugriffstoken und holen Sie sich die IDs

Bamboo läuft headless auf einem Build-Agent. Es kann sich nicht über einen Browser in Ihr Apidog-Konto einloggen, daher authentifiziert sich die CLI stattdessen mit einem Zugriffstoken.

Öffnen Sie in Ihrem Testszenario den CI/CD-Tab. Klicken Sie auf Zugriffstoken hinzufügen, dann auf Token generieren. Kopieren Sie den Wert für einen Moment an einen sicheren Ort; Sie werden ihn in Kürze als Bamboo-Variable speichern, nicht in ein Skript einfügen. Das Token ermöglicht es einem Build-Agent, die Tests Ihres privaten Projekts abzurufen und auszuführen.

Während Sie sich in diesem CI/CD-Tab befinden, generiert Apidog den vollständigen Ausführungsbefehl für Sie. Wählen Sie „Befehlszeile“ als Anbieter aus, und es wird etwas angezeigt, das Sie direkt kopieren können, wobei Ihre Testszenario-ID und Projekt-ID bereits ausgefüllt sind. Dieser kopierte Befehl ist die Grundlage Ihrer Bamboo-Aufgabe. Die Teile, die Sie interessieren:

• Zugriffstoken: Authentifizierung, übergeben als --access-token.
• Testszenario-ID: die numerische ID nach -t, die identifiziert, welches Szenario ausgeführt werden soll.
• Umgebungs-ID: die numerische ID nach -e, die der CLI mitteilt, gegen Staging auszuführen.

Halten Sie diesen generierten Befehl bereit. Die nächsten Schritte passen ihn für Bamboo an.

Schritt 3: Speichern Sie das Token als Bamboo-Planvariable

Codieren Sie niemals ein Token fest in eine Skriptaufgabe. Jeder, der Lesezugriff auf den Plan hat, und jeder, der Build-Logs liest, würde es sehen.

Gehen Sie in Bamboo zu Ihrem Plan, öffnen Sie die Plankonfiguration und suchen Sie den Tab Variablen. Fügen Sie eine neue Variable hinzu. Nennen Sie sie etwas Klares wie APIDOG_ACCESS_TOKEN und fügen Sie das Token als Wert ein. Bamboo maskiert Variablen, deren Namen password, secret oder token enthalten, also benennen Sie sie entsprechend, und der Wert wird in Logs und der Benutzeroberfläche ausgeblendet.

Zur Laufzeit stellt Bamboo Planvariablen Skripten als Umgebungsvariablen zur Verfügung, die präfixiert und großgeschrieben werden, wobei Punkte zu Unterstrichen werden. Eine Variable namens APIDOG_ACCESS_TOKEN ist für Ihre Shell-Aufgabe als $bamboo_APIDOG_ACCESS_TOKEN verfügbar. Sie werden diese referenzieren, niemals das unformatierte Token, im Build-Skript.

Dieselbe Hygiene gilt für alle anderen Geheimnisse, die Ihre Tests benötigen; Datenbankpasswörter, API-Schlüssel von Drittanbietern, Signierschlüssel. Definieren Sie sie als maskierte Bamboo-Variablen und lesen Sie sie über das bamboo_-Umgebungspräfix.

Schritt 4: Fügen Sie die API-Testphase und eine Skriptaufgabe hinzu

Verbinden Sie es nun mit dem Plan. Fügen Sie in der Plankonfiguration eine neue Phase hinzu und nennen Sie sie API-Tests. Fügen Sie einen Job hinzu und dann die Aufgaben in dieser Reihenfolge zum Job.

Aufgabe 1, Quellcode-Checkout. Auch wenn die Tests in der Apidog-Cloud liegen, bietet das Auschecken Ihres Repos dem Agent ein sauberes Arbeitsverzeichnis und ermöglicht es Ihnen, lokale Datendateien (z. B. CSV-Iterationsdaten) zusammen mit Ihrem Code zu committen.

Aufgabe 2, Skript. Dies ist das Herzstück. Wählen Sie eine Skriptaufgabe, stellen Sie den Interpreter auf Shell (oder /bin/sh) ein und verwenden Sie einen Inline-Skriptkörper. Das Skript installiert die Apidog CLI auf dem Agent und führt Ihr Szenario aus.

Die Apidog CLI ist ein npm-Paket, daher benötigt der Agent Node.js v16 oder höher. Wenn Ihre Agenten bereits Node haben, können Sie die Installationszeile überspringen; andernfalls stellen Sie es über Bamboos Fähigkeiten oder einen Docker-basierten Agenten bereit. Hier ist ein vollständiger Skriptkörper:

#!/bin/sh
set -e

# Apidog CLI global auf dem Agent installieren
npm install -g apidog-cli

# Testszenario gegen Staging ausführen, HTML- + CLI-Bericht ausgeben
apidog run \
  --access-token "$bamboo_APIDOG_ACCESS_TOKEN" \
  -t 637132 \
  -e 358171 \
  -r cli,html \
  --out-dir ./apidog-reports

Ersetzen Sie 637132 durch Ihre tatsächliche Testszenario-ID und 358171 durch Ihre Staging-Umgebungs-ID, die Werte aus dem von Apidog in Schritt 2 generierten Befehl. Ein paar Anmerkungen dazu, was jedes Flag bewirkt:

• --access-token liest die maskierte Bamboo-Variable, sodass das Geheimnis niemals im Skript erscheint.
• -t (Kurzform für --test-scenario) wählt das auszuführende Szenario aus. Um stattdessen eine ganze Suite auszuführen, verwenden Sie --test-suite <id>; um einen gesamten Ordner von Szenarien auszuführen, verwenden Sie -f <folderId>.
• -e (--environment) wählt die in Apidog definierte Staging-Umgebung aus, sodass Anfragen mit den richtigen Variablen an den richtigen Host gesendet werden.
• -r cli,html (--reporters) erstellt sowohl einen Konsolenbericht, den Sie im Bamboo-Build-Log sehen werden, als auch einen HTML-Bericht, den Sie als Artefakt veröffentlichen können. Die CLI unterstützt hier auch die Formate json und junit.
• --out-dir steuert, wo Berichte landen. Standard ist ./apidog-reports; explizites Setzen macht den Artefaktpfad vorhersagbar.

Das set -e am Anfang ist wichtig. Es bewirkt, dass die Shell beim ersten fehlerhaften Befehl beendet wird. Die Apidog CLI gibt bereits einen von Null verschiedenen Exit-Code zurück, wenn eine Assertion fehlschlägt, und dieser von Null verschiedene Code teilt Bamboo mit, den Build fehlschlagen zu lassen. Zusammen garantieren sie, dass ein gebrochener API-Vertrag den Build rot färbt, anstatt in den Logs begraben zu werden.

Wenn Sie zuvor API-Tests in GitHub Actions integriert haben, wird Ihnen dies vertraut vorkommen; der Runner und die Flags sind identisch, nur der YAML-gegen-Bamboo-UI-Wrapper unterscheidet sich.

Schritt 5: Veröffentlichen Sie den Testbericht als Bamboo-Artefakt

Ein roter Build sagt Ihnen, dass etwas kaputt ist. Der HTML-Bericht sagt Ihnen, was kaputt ist. Richten Sie es so ein, dass jeder Build den Bericht behält.

Gehen Sie im selben Job zum Tab Artefakte und definieren Sie ein neues freigegebenes Artefakt:

• Name: Apidog-Testbericht
• Ort: apidog-reports
• Kopiermuster: **/*

Nach jedem Build sammelt Bamboo alles im Verzeichnis apidog-reports und hängt es an das Buildergebnis an. Öffnen Sie einen beliebigen Build, gehen Sie zum Tab Artefakte, und Sie können den HTML-Bericht herunterladen oder anzeigen; Anfrage-für-Anfrage-Ergebnisse, die ausgeführten Assertions und der genaue Antworttext für alles, was fehlgeschlagen ist. Dieser letzte Teil spart echte Debugging-Zeit. Anstatt die fehlgeschlagene Anfrage manuell erneut auszuführen, lesen Sie die erfasste Antwort direkt aus dem Build.

Für eine reichhaltigere Anzeige in Bamboo ist der junit-Reporter ebenfalls nützlich. Fügen Sie junit zur -r-Liste hinzu und fügen Sie dann eine JUnit-Parser-Aufgabe hinzu, die auf die JUnit-XML-Datei zeigt. Bamboo rendert dann Testzählungen, Pass/Fail-Aufschlüsselungen und Fehler-Trends nativ in der Build-Zusammenfassung, auf die gleiche Weise, wie es Ihre Unit-Testergebnisse anzeigt.

Schritt 6: Ausführen und das Ergebnis lesen

Starten Sie den Plan für den ersten Durchlauf manuell; in Bamboo, "Plan ausführen" von der Planseite. Beobachten Sie das Build-Log für die API-Testphase. Sie werden sehen, wie npm die CLI installiert, dann die Apidog-Ausgabe durchläuft, Szenario-Name, jede Anfrage, jede Assertion und eine abschließende Zusammenfassungszeile mit Gesamtwerten.

Zwei Ergebnisse:

Alle Assertions sind erfolgreich. Die CLI beendet sich mit 0, die Phase wird grün, der Build ist erfolgreich, und der HTML-Bericht wird trotzdem als Artefakt angehängt, sodass Sie einen Nachweis haben. Gut. Machen Sie es nun automatisch; stellen Sie den Plan so ein, dass er bei jedem Commit an Ihren Hauptzweig ausgelöst wird (Plankonfiguration, Trigger, Repository-Abfrage oder ein Webhook). Von nun an führt jeder Push Ihre API-Suite ohne menschliches Eingreifen aus.

Eine Assertion schlägt fehl. Die CLI beendet sich mit einem Wert ungleich Null, set -e stoppt das Skript, die Phase wird rot und der Build schlägt fehl. Öffnen Sie das Artefakt, finden Sie die fehlgeschlagene Anfrage und lesen Sie die erfasste Antwort. Vielleicht hat sich ein Feld geändert. Vielleicht hat Staging einen 502 zurückgegeben, weil eine Abhängigkeit ausgefallen ist. So oder so wissen Sie innerhalb ein oder zwei Minuten nach dem Commit, der es eingeführt hat, was der gesamte Nutzen ist.

Eine realistische Konsolenzusammenfassung sieht so aus:

┌──────────────┬──────────┬──────────┐
│              │ executed │   failed │
├──────────────┼──────────┼──────────┤
│   iterations │        1 │        0 │
├──────────────┼──────────┼──────────┤
│     requests │        4 │        0 │
├──────────────┼──────────┼──────────┤
│   assertions │       11 │        1 │
└──────────────┴──────────┴──────────┘

  1 assertion failed:
    GET /orders/{orderId}
      expected $.data.status to equal "pending" but got "failed"

Diese eine fehlgeschlagene Assertion ist der einzige Grund, warum die Phase existiert. Sie hat eine Vertragsregression erkannt, die sauber kompiliert und alle Unit-Tests bestanden hat.

Die Suite in CI zuverlässig machen

Ein fehlerhafter API-Test ist schlimmer als gar kein Test, weil er das Team dazu bringt, rote Builds zu ignorieren. Ein paar Gewohnheiten halten die Suite vertrauenswürdig.

• Testdaten isolieren. Jeder Durchlauf sollte das erstellen, was er benötigt, und sich danach selbst bereinigen, wie der oben genannte Erstellen-dann-Löschen-Bestellablauf. Tests, die von einem Datensatz abhängen, der letzten Dienstag erstellt wurde, schlagen fehl, sobald dieser Datensatz sich ändert. Führen Sie die Tests gegen eine dedizierte Staging- oder Testumgebung aus, niemals gegen die Produktion.
• Verwenden Sie datengesteuerte Durchläufe für Abdeckung ohne Duplizierung. Wenn Sie denselben Endpunkt mit zwanzig verschiedenen Eingaben testen müssen, erstellen Sie keine zwanzig Szenarien. Verwenden Sie ein einziges Szenario mit --iteration-data path/to/data.csv (oder -d), und die CLI führt es einmal pro Zeile aus. Committen Sie die CSV-Datei in Ihr Repo, damit sie mit dem Code ausgecheckt wird. Dies ist dasselbe datengesteuerte Testmuster, das Sie lokal verwenden würden, nur von einer Datei in CI gesteuert.
• Die CLI-Version fixieren. npm install -g apidog-cli lädt die neueste Version. Für reproduzierbare Builds fixieren Sie eine bekannte Version, npm install -g apidog-cli@<version>, damit ein CLI-Update das Verhalten zwischen zwei Builds desselben Commits nicht stillschweigend ändert.
• Sinnvolle Timeouts setzen. Fügen Sie --timeout-request 10000 hinzu, um bei einem hängenden Endpunkt schnell fehlzuschlagen, anstatt den Build hängen zu lassen, bis Bamboos eigenes Timeout ihn beendet. Eine klare „Anfragezeitüberschreitung“ ist besser als ein vager, blockierter Build.
• Bereitstellungen an der API-Phase steuern. Da die API-Testphase vor jeder Produktionsbereitstellungsphase läuft und eine fehlgeschlagene Phase den Plan stoppt, kann ein gebrochener Vertrag die Produktion nicht erreichen. Diese Reihenfolge ist Ihr Release-Gate. Es ist die praktische Version des Aufbaus einer echten CI/CD-Pipeline und nicht nur eines Builds, der nur kompiliert.
• Szenarien schnell und fokussiert halten. Eine CI-Suite, die zwanzig Minuten dauert, wird nicht bei jedem Commit ausgeführt; die Leute werden sie auf nächtliche Läufe verschieben und das schnelle Feedback verlieren. Halten Sie die Pro-Commit-Suite auf Ihre kritischen Pfade, Authentifizierung, Kern-CRUD, Zahlungsfluss beschränkt und führen Sie die umfassende Edge-Case-Suite nach Zeitplan aus.

Zusammenfassung

Bamboo schützt Sie bereits vor Code, der nicht kompiliert, und Unit-Tests, die nicht bestehen. Das Hinzufügen einer API-Testphase erweitert diesen Schutz auf die Verträge, die Ihre Dienste tatsächlich über das Netzwerk offenlegen, die Schicht, in der die meisten „aber es funktionierte lokal“-Vorfälle tatsächlich auftreten.

Die Einrichtung ist kurz: Erstellen Sie visuelle, schema-bewusste Tests in Apidog, generieren Sie ein Zugriffstoken, speichern Sie es als maskierte Bamboo-Variable und fügen Sie eine Skriptaufgabe hinzu, die apidog run mit Ihren Szenario- und Umgebungs-IDs ausführt. Veröffentlichen Sie den Bericht als Artefakt, schützen Sie Ihre Bereitstellungsphase damit und lösen Sie den Plan bei jedem Commit aus. Danach läuft es automatisch. Jeder Push überprüft Ihre API, und ein gebrochener Vertrag färbt den Build rot, bevor er zu einem Ausfall werden kann.

Laden Sie Apidog herunter und erstellen Sie Ihr erstes Testszenario, dann fügen Sie den generierten CLI-Befehl in eine Bamboo-Skriptaufgabe ein. Das erste Mal, wenn es eine Regression abfängt, die sauber kompiliert wurde, hat sich die Phase für die zehn Minuten, die die Einrichtung gekostet hat, bezahlt gemacht.