CI/CD

CI/CD

CI/CD CI/CD kontinuierliche Integration. Entwickler mergen kleine Änderungen häufig, ein automatisierter Pipeline baut und testet jede Änderung, und ein validiertes Artefakt bewegt sich den Benutzern ohne auf manuelle Heldentaten zu warten. In einer CapacitorJS-Anwendung muss das gleiche Modell für JavaScript, native iOS- und Android-Projekte, Signaturzertifikate, Geschäftsprozesse im Laden und Geräteverhalten Rechnung tragen.

Inhaltsübersicht

• Was CI/CD Kontinuierliche Integration in der Praxis eigentlich bedeutet
• Die fünf Bausteine jedes CI/CD-Pipelines
  • 1. Trigger
  • 2. Build
  • 3. Test
  • 4. Package
  • 5. Deploy
• Kontinuierliche Lieferung gegenüber kontinuierlicher Bereitstellung
• Ein echter CI/CD-Pipeline für CapacitorJS-Mobilanwendungen
  • Mit einem sauberen Repository beginnen
  • Die nativen Ziele separat aufbauen
  • Kunstwerke absichtlich speichern
• Live-Updates in Ihrem CI/CD-Fluss mit Capgo hinzufügen
  • Kanäle als Releasekontrollen behandeln
  • Publikation nach Validierung anstellen
• Sicherheit und KI in CI/CD-Pipelines heute
  • Nützliche KI von Pipeline-Theater trennen
• Reife-Checkliste für Ihre CI/CD-Konfiguration
  • Den Workflow, nicht die YAML-Datei, überprüfen
  • Zuerst den schmerzhaftesten Riss beheben

Was CI/CD tatsächlich in der Praxis bedeutet

Continuous Integration bedeutet, dass Entwickler ihre Arbeit regelmäßig in einem gemeinsamen Git-Repository kombinieren. Jeder Push oder Pull-Antrag startet eine automatisierte Validierung, die in der Regel die Installation von Abhängigkeiten, Linting, Einheitstests und eine Build umfasst. Das Ziel besteht nicht darin zu beweisen, dass die Anwendung keine Fehler hat. Es geht darum, während die relevanten Änderungen noch leicht verständlich sind, gebrochene Annahmen zu finden.

Für ein CapacitorJS-Projekt könnte die Validierung mit npm cifolgt, gefolgt von Webtests und einer Produktionsbuild. Die Pipeline kann dann npx cap sync um die Web-Assets und native Plugin-Änderungen in die iOS- und Android-Projekte zu kopieren. Ein grünes Ergebnis bedeutet, dass das Repository einen konsistenten Kandidaten produziert hat, nicht nur, dass ein Entwickler Laptop funktioniert hat.

Continuous Delivery erweitert den Prozess über die Validierung hinaus. Die Pipeline produziert eine versionierte Artefakt und hält es bereit für die Veröffentlichung in die Staging- oder Produktionsumgebung. Ein Mensch kann den letzten Release noch genehmigen, insbesondere wenn ein Team eine Compliance-Überprüfung, eine Store-Koordination oder einen kontrollierten Startfenster benötigt.

Continuous Deployment entfernt diesen Genehmigungs-Schritt. Jeder Änderung, die die definierten Überprüfungen besteht, kann automatisch freigegeben werden. Dieser Modell funktioniert nur, wenn Tests, Zugriffsberechtigungen, Rollout-Kontrollen, Überwachung und Rollback-Prozeduren zuverlässig genug sind, um Fehler aufzunehmen.

Mobile Entwicklung macht das Lieferproblem noch komplizierter. Eine Web-Veröffentlichung hat nur eine Laufzeitziel, während eine Capacitor-App möglicherweise eine iOS-Archive, ein Android-App-Bundle, Zertifikate, Berechtigungsprofile, Store-Metadaten und Kompatibilitätsprüfungen auf physischen Geräten benötigt. Capgo-Leitfaden zu den Vorteilen der kontinuierlichen Integration.

Praktische Regel: CI sollte eine schlechte Änderung schnell sichtbar machen. CD sollte eine gute Änderung wiederholbar machen.

Der Pipeline ersetzt das Ingenieururteil nicht. Sie verlagert wiederholbare Arbeit aus den Händen der Menschen, dokumentiert, was passiert ist, und gibt dem Team einen konsistenten Weg von Commit bis Release.

Die fünf Bausteine jeder CI/CD-Pipeline

Ein Pipeline ist einfacher zu entwerfen, wenn man sie als Sequenz von Verantwortlichkeiten anstatt als einzelnes YAML-File betrachtet. Jeder Block beantwortet eine andere Frage.

1. Trigger

Der Trigger ist das Klingelschild. Ein git push Kann schnellere Prüfungen auf einer Feature-Branche durchführen, während ein Pull-Request die Merge-Gate ausführen kann. Ein Tag oder ein Release-Ereignis kann das Paketieren starten, und ein Zeitplan kann Wartungs- oder breitere Geräteprüfungen durchführen.

Wählen Sie Triggers basierend auf dem Risiko. Pull-Requests benötigen schnelles Feedback vor dem Merge. Ein Push zu main Kann verpackbare Artefakte erstellen. Ein Release-Tag sollte ein absichtliches Versandereignis und nicht ein unabsichtliches Branch-Update darstellen.

2. Build

Der Build ist die Küche, in der die Quellcode-code zu etwas wird, das ein anderes System konsumieren kann. In einer CapacitorJS-Anwendung installiert die Arbeit häufig die vom Lockfile definierten Abhängigkeiten, führt den Web-Build aus, führt aus und ruft die Plattform-Tooling auf. npx cap syncDer iOS-Lane kann

durch einen macOS-Runner aufgerufen werden. Der Android-Lane kann Gradle verwenden, um ein xcodebuild oder .aab zu erstellen. .apkDie iOS-Lane kann durch einen macOS-Runner aufgerufen werden. Der Android-Lane kann Gradle verwenden, um ein

oder

Tests act like a health inspector. Unit tests examine isolated JavaScript or TypeScript behavior. Integration tests check boundaries such as storage, navigation, and API clients. Device or emulator checks exercise native plugins, permissions, deep links, and lifecycle behavior that browser tests can’t fully represent.

Die iOS-Lane kann durch einen macOS-Runner aufgerufen werden. Der Android-Lane kann Gradle verwenden, um ein oderzu erstellen. Wenn der Build nicht aus einem sauberen Checkout reproduziert werden kann, versteckt sich die Pipeline hinter einer Abhängigkeit von jemandem's lokalen Maschine. 3. Test Tests wie ein Gesundheitsinspektor. Einheitstests untersuchen isolierte JavaScript- oder TypeScript-Verhaltensweisen. Integrations-Tests prüfen Grenzen wie Speicher, Navigation und __CAPGO_KEEP_0__-Clients. Geräte- oder Emulator-Tests üben native Plugins, Berechtigungen, tiefere Links und Lebenszyklusverhalten aus, das Browser-Tests nicht vollständig darstellen können. Die Analyse des Test-Einflusses kann diesen Schritt praktisch halten. Eine empirische Studie aus dem Jahr 2021 fand heraus, dass tägliche Commits oft nur 3 bis 28 Dateien änderten, während die Abhängigkeitsbeziehungen noch um die 50% oder mehr der TestfälleDie Studie berichtete über mehr als 20% Zeitersparnis in seinem am wenigsten effektiven System und etwa 50% Medianersparnis über die Systeme hinweg, die untersucht wurden, wenn man die betroffenen Tests auswählt, wie in der Studie zum kontinuierlichen Testing dokumentiert ist 4. Paket.

Paketierung ist der Versandbehälter. Die Pipeline zuweist eine Version, sammelt Metadaten, signiert das Artefakt und speichert das Ergebnis. iOS könnte ein IPA erzeugen, während Android häufig ein AAB für den Play-Console erstellt

5. Bereitstellung

Die Bereitstellung ist der Lieferwagen. Es kann ein iOS-Build auf TestFlight hochladen, ein Android-Bundle an einen internen Play-Track senden oder ein Web-Bundle an einen kontrollierten Live-Update-Kanal veröffentlichen. Die Automatisierung der Bereitstellung hilft nur, wenn das Paket vertrauenswürdig ist und der Zielort explizit ist

Automatisierung der Bereitstellung für __CAPGO_KEEP_0__-Projekte Deployment automation guidance for Capacitor projects bietet eine nützliche Referenz für die Verbindung dieser Schritte.

Entfernen Sie einen Block und der umgebende Prozess wird geschwächt. Ohne einen Trigger wartet die Änderung auf manuelle Aktion. Ohne Tests kann die Automatisierung Regressionsfehler schneller liefern. Ohne Verpackung gibt es kein kontrolliertes Artefakt, das gefördert werden kann. Ohne Bereitstellungssteuerungen hängt ein erfolgreicher Build noch von einer Person ab, die wiederholbare, fragile Schritte wiederholt.

Stetige Lieferung gegenüber stetiger Bereitstellung

Die Differenz ist eine Zustimmungsgrenze, aber diese Grenze ändert das Risikoprofil der Organisation.

Mit stetiger Lieferung, baut das Pipeline, testet, verpackt und bereitet eine Veröffentlichung vor. Eine Person genehmigt die Produktionsaktion. Ein regulierter Finanzdienstleistungsunternehmen könnte automatisch jede akzeptierte Commit an die Staging-Umgebung senden, dann die Genehmigung des Release-Managers für die App-Store- oder Play-Store-Bereitstellung erfordern.

Mit stetiger Bereitstellung, führt das Pipeline die letzte Veröffentlichung automatisch durch, nachdem die Richtlinien bestanden haben. Ein Verbraucher-App mit starken automatischen Überprüfungen könnte ein erfolgreicher JavaScript-Bundle an eine begrenzte Zielgruppe veröffentlichen, dann die Ausweitung der Veröffentlichung vornehmen, wenn die Gesundheitssignale akzeptabel bleiben.

Aus einer CapacitorJS-Team, dessen Compliance-Gruppe eine Unterschrift auf jeden native Store-Release erfordert, wird man sich normalerweise für die Lieferung entscheiden. Die Pipeline kann das IPA und AAB produzieren, sie an die entsprechende Überprüfungsdestination senden und auf die Zustimmung warten. Genehmigte JavaScript- und CSS-Änderungen können in einem separaten Live-Update-Prozess folgen, wenn die Organisation dies erlaubt.

Aus einem Casual-Spielteam kann man sich für die Bereitstellung für niedrigrisikohaften Web-Schichten und die Lieferung für native Releases entscheiden. Diese Aufteilung ist oft realistischer als die Anwendung einer einzigen Politik auf jeden Artefakt.

Die wichtigste Abwägung ist nicht die Geschwindigkeit. Die Lieferung bevorzugt explizite menschliche Verantwortlichkeit, während die Bereitstellung eine getestete Systemfähigkeit bevorzugt, die konsistente Entscheidungen treffen kann. Keine dieser Modelle ist automatisch sicherer. Ein manueller Klick kann Kontext fangen, den Tests verpassen, aber er kann auch ein ungedokumentierter Engpass werden. Eine automatische Bereitstellung kann die Verzögerung reduzieren, aber nur, wenn das Team einen schlechten Release erkennen und die vorherige Version ohne Improvisation wiederherstellen kann.

Achtung: Eine echte CI/CD Pipeline für CapacitorJS-Mobilanwendungen

Eine nützliche GitHub Actions-Arbeitsfläche macht die Repository-Übermittlungskarte sichtbar. Die genauen Arbeitsflächenversionen und die Signierungseinstellung variieren, aber die Sequenz sollte verständlich bleiben.

Beginnen Sie mit einem sauberen Repository

Eine Push zu main kann die Arbeitsfläche auslösen. Die ersten Jobs überprüfen den Commit und wählen die erforderliche Node.js-Version. npm ci installiert genau das, was der Lockfile deklariert, was verhindert, dass der Runner eine andere Abhängigkeitsstruktur löst.

Die Web-Validierungsstufe kann dann Befehle wie folgt ausführen:

• Lint: Führen Sie den Projekt-ESLint-Befehl aus und beenden Sie die Meldung, wenn es zu Verstößen kommt, die das Mergen blockieren sollten.
• Einheitstests: Führen Sie Jest in einem nicht interaktiven Modus aus, sammeln Sie die Ergebnisse und bewahren Sie nützliche Protokolle auf.
• Weboberbau: Erstellen Sie das Produktionspaket, das Capacitor paketiert.
• Capacitor-Synchronisierung: Ausführen npx cap sync so erhalten native Projekte Web-Assets und Änderungen an Plugins.
• Konfigurationsvalidierung: Überprüfen Sie, ob die Capacitor-Konfiguration die erwarteten Anwendungsidentifikatoren, Plattformeinstellungen und Umgebungsvariablen enthält.

Das Workflow-File steuert die Orchestrierung, während package.json die Projekt-Befehle steuert. Die Capacitor-Konfiguration steuert das Synchronisierungsverhalten. Durch die Trennung dieser Verantwortlichkeiten werden Fehler einfacher zu diagnostizieren. Die Capgo-Anleitung zur kontinuierlichen Integration beschreibt das Integrationsmuster in mehr Details.

Bauen Sie die native Ziele unabhängig voneinander

iOS erfordert einen macOS-Runner, da Xcode Teil des Toolchains ist. Die Aufgabe restauriert Abhängigkeiten, installiert oder abruft Zertifikate und Provisioning-Profile und ruft xcodebuild oder Fastlane. Ein Setup, das fastlane match das Verhältnis zwischen Signiermaterial und dem Buildprozess verwalten kann, sollte jedoch nie private Zertifikate oder Profile im Repository enthalten.

Android kann auf einem Linux- oder macOS-Runner ausgeführt werden. Die Aufgabe ruft Gradle auf, oft über eine Befehlszeile wie ./gradlew bundleRelease, und signiert das resultierende AAB mit einem durch verschlüsselte CI-Schlüssel referenzierten Keystore.

Store Artefakte absichtlich

Der Workflow sollte die IPA und AAB als benannte Artefakte hochladen, die an den Commit- oder Release-Identifier gebunden sind. Spätere Aufgaben können diese exakten Dateien an TestFlight oder einen internen Track im Play Console übermitteln. Diese Trennung ist wichtig, da die Wiederherstellung nach Genehmigung ein anderes Artefakt als das, das die Rezensenten getestet haben, erzeugen kann.

Eine Matrixstrategie kann iOS- und Android-Läufe gleichzeitig ausführen. Das reduziert die Wartezeit ohne Plattform-spezifische Fehler zu vermischen. Es macht auch den endgültigen Status klarer: Die Web-Ausführung kann erfolgreich sein, während die Signierung für Android fehlschlägt, und der Workflow sollte diese Unterscheidung anstatt eines transparenten Ergebnisses anzeigen.

Geheime Informationen sollten im verschlüsselten Geheimnis-Store des CI-Anbieters aufbewahrt werden. Die Aufgabe sollte nur die erforderlichen Anmeldeinformationen erhalten, für die kürzestmögliche Dauer. Die Protokolle müssen auf unbeabsichtigte Geheimnis-Ausgaben überprüft werden, insbesondere wenn Befehlszeilenwerkzeuge die Konfiguration während fehlgeschlagener Builds ausgeben.

Capgo zum Hinzufügen von Live-Updates zu Ihrem CI/CD-Flow hinzufügen.

A Designer ändert die Einrichtungskopie am Freitag nachmittag. Die Änderung betrifft JavaScript und CSS, nicht native Swift, Kotlin oder einen Capacitor-Plugin. Der Entwickler committet es, öffnet einen Pull-Request und lässt die normalen Checks die Web-Bundle validieren.

Nachdem npm ci, das Web-Build, Tests und npx cap sync gelingt, kann ein Release-Job die resultierenden Web-Assets an einen ausgewählten Capgo-Kanal veröffentlichen. Der Kanal kann eine Staging-Umgebung, eine Produktionsumgebung, eine Beta-Audience oder einen anderen kontrollierten Gruppe darstellen. Die Benutzer erhalten das Bundle über die App-Update-Mechanismus anstatt auf ein neues Store-Binary zu warten.

Die wichtige Grenze ist native code. Eine Änderung an JavaScript, CSS, Kopie oder kompatibler Konfiguration kann dem live-Update-Path folgen. Eine Änderung an native Plugins, Berechtigungen, Zulassungen oder Plattform code erfordert jedoch ein neues iOS- oder Android-Binary und den relevanten Store-Prozess.

Kanäle als Release-Kontrollen behandeln

Ein Staging-Kanal ermöglicht es dem Team, das Bundle mit einer kontrollierten Audience zu validieren, bevor es zur Produktionspromotion kommt. Die Versionspinning kann eine bekannte App-Version auf einem kompatiblen Bundle halten, während neue native Binaries einen anderen Release-Path verwenden. Diese Trennung hilft, Web code an einen native Runtime zu senden, der es nicht versteht.

A Rollback sollte eine bekannte gute Bundle wiederherstellen, nicht einen Entwickler dazu bringen, die vorherige Build manuell zu rekonstruieren. Der operative Wert kommt von der Verbindung von Veröffentlichung, Versionsgeschichte, Zielgruppenzielung und Lieferstatus zum gleichen Releaseprozess.

Veröffentlichen Sie nach der Validierung.

Der Capgo CLI Schritt gehört nach dem normalen Web-Build und den Überprüfungen. Die Authentifizierung sollte ein CI-Schlüssel oder einen geschützten Umgebungsvariablen verwenden, und die Produktionsschaltung sollte auf den Zweig, Tag oder die Genehmigungsrichtlinie beschränkt werden, die einen bewussten Release darstellt.

Der Capgo GitHub Actions-Integration-Leitfaden zeigt, wie dieser Veröffentlichungsschritt in automatisierten Workflows integriert werden kann. Die breitere Prinzipien gelten unabhängig vom Anbieter: Bauen Sie einmal, überprüfen Sie das Artefakt, veröffentlichen Sie es in einem benannten Umfeld und behalten Sie genug Metadaten bei, um genau zu bestimmen, was die Benutzer erhalten haben.

Für ein Team erstellt dies zwei verbundene Bahnen. Die Speicherbahn verteilt native Fähigkeiten. Die Live-Update-Bahn verteilt genehmigte Web-Schichtenänderungen. Die Trennung dieser Bahnen verhindert das gemeinsame Fehler, jedes Capacitor Änderung als vollständige Speicherfreigabe oder unkontrollierte Kurzschluss zu behandeln.

Sicherheit und KI in CI/CD Pipelines heute

Pipeline-Geschwindigkeit kann nicht für schwache Release-Kontrollen entschädigen. Ein mobiler Workflow handhabt Signierungszertifikate, dritte Abhängigkeiten, native Build-Tools und code , die auf Benutzergeräte zugreifen können. Die Sicherheit gehört in den gleichen automatisierten Pfad wie Linting und Tests.

Nützliche Steuerelemente umfassen Abhängigkeitsprüfungen mit npm audit oder Snyk, geheime Detektion mit gitleaks, SBOM-Generierung, signierte native Artefakte, eingeschränkte CI-Berechtigungen und geschützte Produktionsumgebungen. Live-updaten von Bundeln benötigen auch eine Signaturprüfung und Kanalsteuerungen, damit ein gültiges Anwendungsprogramm tamperierten oder inkompatiblen Inhalt ablehnen kann.

Eine 2026er Studie von GitHub Actions fand heraus, dass fünf empfohlene Sicherheitsmaßnahmen einen Durchschnittsimplementierungsgrad von nur 17,5% in etwa 340.000 öffentlichen Repositories, während eine Umfrage von 102 Entwicklern mangelnde Bewusstsein und erwartete Betriebslast als Hauptblocker identifizierte, wie die gemeldeten CircleCI-Sicherheitsergebnisse zeigen. Der Riss deutet darauf hin, dass Teams oft eine einfache Einführungsplanung benötigen, anstatt ein weiteres Sicherheitsprodukt.

Trenne nützliche AI von Pipeline-Theater

AI kann dabei helfen, fehlgeschlagene Protokolle zu summarisieren, wiederkehrende flache Testfehler zu gruppieren, Release-Notizen zu entwerfen und wahrscheinliche Konfigurationsfehler zu empfehlen. Diese Verwendung hält einen Menschen für die Entscheidung verantwortlich und macht die Ausgabe leicht zu überprüfen.

Behauptungen über selbstheilende Pipelines verdienen mehr Vorsicht. Eine 2026er Industrieumfrage berichtete, dass 73% der Organisationen keine AI in ihren Pipelines verwendeten, während 60% von Nichtnutzern wurde eine unklare Wertigkeit oder Verwendungszwecke genannt, 36% wurde Misstrauen gegenüber den generierten Ergebnissen genannt und 33% wurde die Privatsphäre als Bedenken genannt, wie im TeamCity-Umfragebericht beschrieben.

Die Zahlen sollten nicht dazu führen, dass grundlegende Sicherheitsmaßnahmen verzögert werden. Beginnen Sie mit der Geheimhaltung, der Sichtbarkeit von Abhängigkeiten, der Signierung und dem minimalen Zugriff. Fügen Sie AI hinzu, wo sie die Untersuchungszeit reduziert, ohne dass ein nicht überprüfter Modelloutput die Freigabe eines Produktionsreleases ermöglicht. Pipeline-Sicherheitshinweise für Capacitor-Anwendungen Können dabei die Kontrollelemente um die mobilen Risiken herumrahmen.

Reife-Checkliste für Ihre CI/CD-Einrichtung

Aufrechte Pipelines sind nicht diejenigen mit den meisten Aufgaben. Es sind diejenigen, die dem Team zuverlässige Beweise an jedem Releasepunkt liefern.

Überprüfe das Workflow, nicht das YAML

Benutze diese Kontrollpunkte, um das System zu bewerten, das du verwendest.

1. Konfigurierte Trigger: Jeder Pull-Request und relevante Push startet die erwartete Workflow. Der Signal ist ein sichtbarer Lauf, der an den Commit angehängt ist, nicht eine dokumentierte Absicht.
2. Automatisierte Tests sperren Merges: Lint- und Unit-Tests müssen vor dem Merge erfolgreich sein. In GitHub sollte eine erforderliche Statusprüfung einen Merge verhindern, wenn die Aufgabe fehlschlägt.
3. Signierte Artefakte gespeichert: Der Workflow erstellt signierte IPA- und AAB-Dateien und speichert sie mit identifizierbarem Build-Metadaten. Eine spätere Release sollte die gespeicherten Artefakte verwenden und nicht von neuem aus dem Speicher aufbauen.
4. Getrennte Umgebungen: Staging und Produktionsumgebung verwenden unterschiedliche Anmeldeinformationen, Kanäle und Genehmigungsregeln. Eine Staging-Veröffentlichung sollte nicht versehentlich in die Produktionsumgebung veröffentlicht werden.
5. Automatisierter Bereitstellungsprozess: Die Pipeline kann ein genehmigtes Artefakt an seinen bestimmten Zielort senden, ohne dass jemand Dateien zwischen Maschinen kopiert.
6. Rückgängigmachung bereit: Das Team kann eine vorherige native oder web-schichtige Version durch eine dokumentierte Aktion wiederherstellen. Eine Rückgängigmachungsverfahren, das nur in den Notizen eines einzelnen Ingenieurs existiert, ist nicht betriebsbereit.
7. Überwachung und Warnungen: Das Team verfolgt die Pipeline-Dauer, fehlgeschlagene Ausführungen, Bereitstellungsresultate und die Gesundheit der Anwendung. Ein erfolgreicher Job beweist nicht, dass die Benutzer die Aktualisierung erhalten oder toleriert haben.

Die schmerzhafteste Lücke zuerst beheben

Machen Sie die Checkliste nicht zu einem einjährigen Plattformprojekt. Wählen Sie die fehlende Fähigkeit aus, die am häufigsten schmerzhafte Blockierung darstellt, beheben Sie sie innerhalb eines Sprints und führen Sie die Checkliste erneut durch.

Wenn Entwickler auf manuelle Builds warten, automatisieren Sie das Build. Wenn Merges aufgrund zu spät laufender Tests fehlschlagen, machen Sie die Überprüfungen erforderlich. Wenn eine schlechte JavaScript-Ausgabe eine Store-Submission erzwingt, dokumentieren und schützen Sie einen lebendigen Update-Weg, bei dem Ihr Produkt und Compliance-Politik es zulassen.

Senior-Ingenieur-Regel: Eine Pipeline ist reif, wenn ein anderer Ingenieur sie sicher während eines Vorfalls betreiben kann.

Das Standard enthüllt Schwachstellen schnell. Ein grünes Häkchen zählt nur, wenn das Team weiß, was es validiert hat, wohin das Artefakt gegangen ist, wie die Benutzer es erhalten haben und wie man sich wiederherstellen kann, wenn die Veröffentlichung schlecht verhält sich.

Capgo verbindet die CI/CD-Workflows von CapacitorJS mit kontrollierten Live-Update-Deliverys, mit signierten Web-Bundles, Kanälen, Versionsgeschichte und Rollback-Unterstützung für geeignete JavaScript- und Asset-Änderungen. Besuchen Sie Capgo zum Beispiel, um zu sehen, wie es sich neben Ihren bestehenden GitHub Aktionen, Speicher und Veröffentlichungsprozessen einfügen kann.