Erklärung der Build-Typen: Von lokalem zu Produktionsbuild

Sie öffnen ein Projekt und sehen build:ios:dev, build:android:qa, build:staging, build:release, build:prod, plus ein paar Shell-Skripte, die niemand berühren möchte. Dann sagt jemand: ‘Können Sie bis zum Ende des Tages einen Staging-Build für den Kunden erstellen?’ Wenn Sie ein mittlerer mobiler Entwickler sind, fühlt sich diese Anfrage oft sehr vage an. Welche Konfiguration? Welche Signaturidentität? Welcher Backend? Welcher Verteilungsweg?

Diese Verwirrung kommt oft daher, dass man Build-Typen als eine flache Liste behandelt. Das sind sie nicht. Sie sind ein Workflow. Jeder Build existiert, um ein bestimmtes Problem an einem bestimmten Punkt zwischen Ihrem Laptop und einem Gerät des Benutzers zu lösen.

A build is not just a compiled app. It’s a version of your app assembled for a purpose, an audience, and an environment. Some builds exist to help you debug. Some exist to help QA break things safely. Some exist so release engineering can produce a trustworthy artifact. Some exist so product teams can ship changes with less risk.

Wenn Ihre lokale Konfiguration noch unsicher anfühlt, bevor etwas anderes losgeht, bringen Sie das zunächst unter Kontrolle mit einer ordentlichen Capacitor lokale Umgebungsanpassung auf. Die Komplexität von Builds wird viel einfacher zu verstehen, wenn Ihre Grundausstattung vorher vorhersehbar ist.

Tabelle der Inhalte

• Entwirren Sie die Welt der Software-Builder
• Das Spektrum der Builds Lokal vs CI-Builds
  • Lokale Builds
  • CI Builds
• Grundlegende Build-Flavours Debug vs Release
  • Debug-Builds
  • Veröffentlichungs-Builds
  • Warum Teams immer noch falsch liegen
• Builds zu Distributionsumgebungen abbilden
  • Nightly und Canary
  • Staging und Beta
  • Private Distribution-Builds
  • Produktion
  • Software-Entwicklungsarten und ihre Merkmale
• Die kritische Rolle der Code-Signierung
  • Was Signieren tatsächlich beweist
  • Wie sich das Signieren durch den Zielort ändert
• Die Organisation von Releases mit CI/CD und Update-Kanälen
  • Ihr Pipeline ist der Buildvertrag
  • Kanäle fügen Kontrolle nach dem Versand des Binärs hinzu
• Gute Praktiken für einen modernen Build-Workflow

Die Welt der Software-Builder entwirren

Die häufigste Fehlannahme, die ich sehe, ist, dass Build-Namen die ganze Geschichte erzählen. Sie tun das nicht. staging Könnte bedeuten “Release-Variante, die sich auf Staging-APIs richtet.” In einem anderen Repository könnte es bedeuten “Debugbare QA-Artikel mit simulierten Zahlungen.” In einem dritten könnte es bedeuten “Produktionssignierte Build, der privat verteilt wird.”

Das ist der Grund, warum Teams verwirrt werden. Der Label ist nur nützlich, wenn man versteht, was für eine Aufgabe das Build erfüllt.

Ein nützlicher Weg, um sich die Arten von Builds vorzustellen, ist dieser:

• Lokale Builds Ein Entwickler unterstützen, schnell voranzukommen.
• CI-Builds Einen gemeinsamen Wahrheitsstandard für das Team erstellen.
• Debug- und Release-Flavours Definieren, wie die App kompiliert und instrumentiert wird.
• Verteilungsbuilds Definieren, wer die App erhält und wie.
• Signierte Builds Bestimmen, ob die Plattform das Artefakt vertraut.
• Channel-basierte Updates Bestimmen, wie Änderungen nach der Installation weitergehen.

Das sind keine konkurrierenden Kategorien. Sie stapeln sich.

A “Staging-Build” ist selten ein einzelnes Ding. Es handelt sich meistens um eine Combination aus Geschmack, Umgebung, Signierung und Verteilungsentscheidung.

Aus diesem Grund können zwei Teams beide sagen “wir brauchen eine Beta-Build” und meinen völlig unterschiedliche Artefakte.

Dies ist am wichtigsten auf mobilen Geräten, da jede Schritt Reibung hinzufügt. Die native Kompilierung, Geheimnisse, Bereitstellung, App-Store-Tracks, Zugriff für Tester, Umgebungs-Konfiguration und Rollback müssen alle in Einklang gebracht werden. Wenn ein Teil nicht stimmt, wird Ihr Release-Prozess zu tribalischem Wissen. Dann geht ein Ingenieur auf Urlaub und niemand kann sauber ausliefern.

Die Teams, die dies gut handhaben, memorisieren keine mehr Skripte. Sie definieren Build-Typen als Qualitätsgrenzen. Jede Grenze senkt einen anderen Risikotyp: kaputte code, falsche Konfiguration, schlechte Signierung, schlechte Verteilung oder schlechte Wiederherstellung.

Das Build-Spektrum: Lokale vs CI Builds

Eine lokale Build ist die Version, die du für dich selbst machst. Eine CI-Build ist die Version, die das Team vertrauen kann.

Dies klingt offensichtlich, aber ein Großteil der Build-Schmerzen beginnt, wenn Teams diese beiden miteinander vermischen. Jemand beweist “es funktioniert auf meinem Rechner”, dann schlägt die Branch in CI fehl, weil die lokale Umgebung implizit auf einen gecacheten Abhängigkeit, einen manuell bearbeiteten Datei oder eine Signierungs-Asset angewiesen war, das nie in die Automatisierung kam.

Lokale Builds

Lokale Builds sind privat, schnell und verbrauchbar. Du verwendest sie, um sofortige Fragen zu beantworten.

Kann die Bildschirmoberfläche rendern? Initialisiert sich der native Plugin? Hat sich das Gradle- oder Xcode-Update auf die Kompilierung ausgewirkt? Kann man den Crash mit aktivierten Protokollen reproduzieren?

Ein guter lokaler Build bevorzugt Geschwindigkeit gegenüber Zeremonie. Er enthält oft lose Überprüfungen, umfassende Protokolle, Entwickler-Toggle und temporäre Instrumentierung. Das ist in Ordnung. Seine Aufgabe ist schneller Feedback.

Was nicht funktioniert, ist die Förderung eines lokalen Builds zu etwas Wichtigerem als er ist. Ein lokaler Build sollte nie das Release-Artikel werden, weil er auf einem Laptop erfolgreich kompiliert wurde.

CI-Builds

CI-Builds sind langsamer, weil sie persönliche Maschinenzustände aus der Gleichung entfernen und den Build-Prozess wiederholbar machen.

Wenn CI gesund ist, funktioniert es drei Dinge gut:

• Von Grund auf neu aufbauen: Es beweist, dass das Projekt ohne versteckte lokale Annahmen kompiliert.
• Team-level-Überprüfungen durchführen: Einheitstests, Linting und Paketierungsregeln finden immer an derselben Stelle statt.
• Einen nachvollziehbaren Artefakt erzeugen: Das Team kann einen Build auf einen Commit, eine Zweig und eine Pipeline-Ausführung zurückbinden.

Das ist der Grund, warum ich die Werkstatt-gegen-Fabrik-Analogie mag. Ihr Laptop ist der Werkbank, wo Sie iterieren.

Wenn Ihr Team noch immer manuell entscheidet, welcher Skript wo ausgeführt wird, zentralisieren Sie diese Logik in der Automatisierung. Ein praktischer Leitfaden ist dieser Guide zu Verwaltung von Entwicklungs- und Produktionsbuilds mit GitHub Aktionen.

Praktische Regel: Wenn QA, Produkt oder Support das Artefakt benötigt, sollte es aus der CI und nicht von einem Entwicklerrechner kommen.

Einmal akzeptiert man das, wird der Rest des Build-Lebenszyklus leichter. Die Auswahl der Flavor, das Signieren, die Umgebungsinjektion und die Verteilung gehören in einen Pipeline, den jeder Teammitglied überprüfen kann.

Kern-Flavours Debug vs Release

Es gibt viele Bezeichnungen für Builds, aber unter all dem Namen zählen zwei Flavours normalerweise am meisten: debug und release.

Sie existieren, weil Entwickler und Endnutzer entgegengesetzte Dinge benötigen.

Debug-Builds

Ein Debug-Build soll Menschen dabei helfen, das Verhalten zu überprüfen. Er hält normalerweise mehr Metadaten auf, erleichtert die Fehlersuche und vermeidet aggressive Optimierungen, die Probleme verbergen können.

Es gibt eine nützliche Analogie aus der Bauausführung. Spezifikationen fallen üblicherweise in vorschriftsmäßige, leistungsbasierte, eigentumsrechtlicheund referenzstandard Arten, und ein Debug-Build passt sich gut zu einer vorschriftsmäßige Analyse-Aufbau, da er genauere Werkzeuge und Methoden für die Analyse vorgibt, während ein Release-Aufbau einem performance An Ansatz, der sich auf das erforderliche Ergebnis konzentriert, wie im Dieser Aufschlüsselung der Bauvorschriften-Typen.

In der Praxis ist ein Debug-Build der Ort, an dem Sie Dinge wie:

• Lesbarer Diagnoseoutput: Stackspuren, Konsole-Ausgabe und Symbole, die Ihnen helfen, den Fehler zu finden.
• Entwickler-Vorteile: Funktionstasten, Testmenüs und Featureschalter, die für Endnutzer ungeeignet wären.
• Low-Friction-Iteration: Kürzere Installations- und Ausführungszyklen zählen mehr als ein polierter Paket.

Debug-Builds sind nicht 'schlecht'. Sie sind zielgerichtet.

Release-Builds

Release Builds sind für Geräte im Feld gedacht. Das ändert die Prioritäten sofort.

Jetzt kümmern Sie sich um die Paketintegrität, das Startverhalten, eine enge Sicherheitsstellung, kleinere Payloads und vorhersehbare Laufzeitmerkmale. Sie möchten auch weniger ungewollte Eingangspunkte für Inspektion oder Missbrauch.

Der Kompromiss ist einfach. Alles, was Debug Builds einfacher zu inspizieren macht, neigt dazu, Release Builds weniger geeignet für die Produktion zu machen.

Hier ist die Entscheidungsgrenze, die ich mit Teams verwende:

Weshalb Teams dies immer noch falsch machen

Die größte Quelle der Verwirrung ist die Mischung von "Umgebung" mit "Flavor."

Eine Build kann sein Release-Flavor, die auf Staging-Dienste ausgerichtet ist. Das ist üblich für QA, weil man eine Produktionsähnliche Verhaltensweise mit nicht-produktionsrelevanten Daten möchte. Eine Build kann auch sein Debug-Flavor, die auf Entwicklungsdienste ausgerichtet ist zur täglichen Programmierung. Das sind unterschiedliche Achsen.

Ein Großteil des Skript-Schwalls entsteht, weil Teams alle möglichen Combinationen in Paketnamen einbauen, anstatt die Matrix zu dokumentieren.

Schicken Sie die Release-Flavor, wenn Nicht-Entwickler das Benutzerinterface testen. Halten Sie die Debug-Flavor für Ingenieurarbeit und bewusste Fehlerbehebung.

Diese eine Regel eliminiert eine Menge ungewollter Komplexität.

Builds auf Verteilungs-Umgebungen abbilden

Die meisten Diskussionen über die verschiedenen Build-Arten enden zu früh. Sie erklären lokale, Debug- und Release-Builds und ignorieren dann die schwierigere Frage: Wohin geht dieser Build?

Das Ziel ändert, was der Build enthalten sollte, wie er signiert werden sollte und wer ihn erhalten sollte.

Ein praktischer Build-Workflow bewegt sich normalerweise durch mehrere Umgebungen, jede mit einer anderen Zielgruppe und einem anderen Risikobewusstsein. Wenn Sie an Capacitor-Apps arbeiten, hilft es auch, eine klare mentale Trennung zwischen Entwicklungs- und Produktionsanwendungsverhalten in Capacitor zu halten,weil viele „Build-Probleme“ tatsächlich Umgebungsfehler sind.

Nightly und Canary

Diese sind Vorwarnungsbuilds. Sie sind für Ingenieure, QA oder eine kleine interne Gruppe gedacht, die mit ungeschärften Kanten umgehen kann.

Ein Nightly-Build wird normalerweise auf einem Zeitplan oder aus dem neuesten Hauptzweig erstellt. Ein Canary-Build wird absichtlich einer kleinen Zielgruppe zugänglich gemacht, bevor er breiter ausgerollt wird. Ich betrachte sie als Lernmittel und nicht als Versprechen von Stabilität.

Sie sind nützlich, wenn Sie Fragen wie:

• Integriert sich der Zweig sauber über Module?
• Hat eine native Abhängigkeitsaktualisierung eine bestimmte Gerätefamilie gebrochen?
• Können interne Tester Regressionsfehler vor breiterer Beta-Veröffentlichung erkennen?

Was nicht funktioniert, ist Canary-Builds an Menschen zu geben, die sich auf polierte Software freuen. Sie erhalten laute Feedback, und die falsche Zielgruppe wird normalen Churn als Releaseproblem bezeichnen.

Staging und Beta

In diesem Punkt spielt die Produktqualität mehr als die Ingenieurskomfort.

A staging or beta build should feel close to what real users will get. That usually means release flavor, production-like configuration where possible, and controlled distribution through platform tools such as TestFlight or Google Play testing tracks.

Das Publikum ändert sich hier:

• QA validiert Rückschritte, Workflows und Akzeptanzkriterien.
• Produktmanager überprüfen das Verhalten in einer realistischen Umgebung.
• externe Tester validieren Benutzbarkeit, Geräteabdeckung und Randfälle.
• Support- oder Erfolgsteams können zukünftige Änderungen ankündigen.

Der Fehler hier ist, Beta als "nur noch ein Debug-Build" zu behandeln. Wenn Ihre Tester echte Benutzerflüsse bewerten, benötigen sie Releasebedingungen.

Private Verteilungsbuilds

Einige Apps benötigen Builds, die nie an die breite Öffentlichkeit gehen oder müssen zuerst einer kleineren Zielgruppe zugänglich sein.

Das umfasst Client-spezifische Builds, interne Mitarbeiter-Apps, regulierte Workflows, Feldbetriebswerkzeuge und Unternehmens-only-Verteilungen. Diese erfordern oft strengere Kontrolle über die Personen, die das App installieren dürfen, und die Backend, die sie erreichen.

Hier wird auch die Namensgebung gefährlich. Teams sagen oft "Unternehmensbuild" an, meinen aber tatsächlich eines von mehreren Dingen.

• eine privat signierte interne App
• Eine im App-Store verteilte Anwendung mit internen Zugriffskontrollen.
• ein Kundenanpassungsbündel
• eine Vorabversion für Stakeholder-Überprüfungen

Diese sind unterschiedliche Betriebsmodelle. Halten Sie sie in Ihrem Pipeline und Ihren Namen getrennt.

Produktion

Produktionsbuilds sind die öffentliche Zusage. Sie gehen in den App Store, Google Play Store oder den entsprechenden genehmigten Kanal für Ihre Benutzer.

An diesem Punkt sollte das Build langweilig sein. Das ist ein Kompliment.

Sie möchten, dass ein Produktionsbuild reproduzierbar, korrekt signiert, in Release-Bedingungen getestet und an einen Rollback-Plan gebunden ist. Sie möchten keine letzten Minuten manuellen Änderungen, Maschinen-spezifische Hacks oder 'Wir werden es in der nächsten Build reparieren' Kompromisse.

Hier ist die Übersicht.

Software-Bauarten und ihre Merkmale

Die richtige Build-Art ist diejenige, die der Zielgruppe entspricht und die Risikotoleranz. Die meisten Fehler bei der Veröffentlichung passieren, wenn Teams diese Abstimmung verpassen.

Die kritische Rolle der Code-Signierung

Eine Build-Datei allein bedeutet nichts auf mobilen Geräten. Die Plattform benötigt Beweise, dass sie von einem vertrauenswürdigen Quelle stammt und dass niemand sie nach der Erstellung verändert hat. Diese Beweise sind code-Signierung.

Wenn Sie bereits einmal eine Build hatten, die perfekt kompiliert, aber nicht installiert, hochgeladen oder gestartet wurde, dann war wahrscheinlich die Signierung der Fehler.

Was Signierung eigentlich beweist

Für ein mobiles Team tut code-Signierung drei Dinge.

• Authentizität: es bindet die App an den Entwickler oder die Organisation, die sie produziert hat.
• Integrität: es hilft dabei, zu beweisen, dass das Artefakt seit der Signierung nicht manipuliert wurde.
• Zustimmung: besonders auf Apple-Plattformen kontrolliert es auch, wo und wie die App ausgeführt werden darf.

Das dritte Punkt verwirrt viele Entwickler. Signierung ist nicht nur Identität. Sie ist auch Erlaubnis.

Daher kann die gleiche App code je nachdem unterschiedliche Signiermaterial benötigen, ob Sie sie lokal auf einem Gerät ausführen, sie an Tester verteilen, intern bereitstellen oder sie in den Store einreichen möchten.

Wie sich Signierung durch Ziel ändert

Dies ist das mentale Modell, das den Prozess sinnvoll hält: Signierung folgt der Verteilung.

A lokale Entwickler-Installation verwendet eine Sätze von Identitäten und Berechtigungen. Ein Beta-Build, das über TestFlight gesendet wird, verwendet einen anderen. Ein interner Verteilungsweg erfordert möglicherweise wiederum andere Profile. Eine öffentliche Veröffentlichung im App Store hat ihre eigenen Signierungsanforderungen und -kompatibilitäts-Pakete.

Deswegen ist 'die Signatur ändern' selten ein kleiner Wunsch. Sobald sich die Signatur ändert, können sich die zulässigen Zielorte für das Artefakt ändern.

Ein diszipliniertes Setup umfasst normalerweise:

• Signierungsassets in CI speichern: keine auf persönlichen Laptops.
• Eine klare Trennung nach Ziel: Entwicklung, private Testung, Enterprise, App-Store-Veröffentlichung.
• Rotation und Zugriffssteuerungen: besonders wenn externe Dienstleister oder mehrere Produktteams die Infrastruktur nutzen.
• Auditability: Sie müssen wissen, welche Pipeline welche Signaturidentität verwendet hat.

Wenn Ihr Team Web-Updates innerhalb einer Capacitor-App bereitstellt, gibt es auch einen zweiten Signierungsschicht, über den nachgedacht werden muss. Diese Übersicht über End-to-End-Sicherheit für Capacitor-Updater code-Signierung is useful because it separates native binary trust from update-package trust.

Probleme bei der Signierung kommen nicht oft von der Kryptographie. Sie kommen von unklarer Eigentümerschaft, manueller Handhabung und Build-Pipelines, die verbergen, welche Identität angewendet wurde.

Behandeln Sie Signiermaterial wie Produktionsinfrastruktur, weil das, was es ist.

Orchestrating Releases mit CI/CD und Update-Kanälen

Bei einer erfahrenen Mannschaft ist das Problem nicht die Kenntnis der verschiedenen Buildarten, sondern die Koordination ohne menschliches Zufallsspiel.

Diese Koordination gehört in CI/CD.

Ihr Pipeline ist der Build-Vertrag

Ein zuverlässige Pipeline sollte jede Frage beantworten, die sie immer wieder beantworten muss:

• Was ist dieser Build für?
• Welche Variante verwendet er?
• welche Umgebungsvariablen es erhält
• welche Tests es bestehen muss
• welche Signatur identität zutrifft
• woher das Artefakt geliefert wird

That structure mirrors a good technical specification. A well-formed spec should include Zweck und Umfang, funktionale Anforderungen, gestalterische Anforderungen, technische Standards, Testanforderungen, Lieferanforderungen und Anforderungen für Support oder Wartung, wie im Artikel beschrieben Technische Spezifikationsanleitung. That same discipline makes CI/CD easier to reason about because the pipeline stops being a bag of scripts and becomes an executable release policy.

In practice, the pipeline should decide, not the engineer running it manually. Branch rules, tags, approval steps, signing context, and deployment targets should all be encoded.

Was funktioniert:

• Branch-getriebene Absicht: main, Releasebranches und Tags lösen unterschiedliche Workflows aus.
• Explicites Artefaktbezeichnen: Flavor, Umgebung und Ziel sind im Ausgabe sichtbar.
• Stattdessen Promotion anstatt Neubau von Hand: Validierte Artefakte werden weitergeleitet, anstatt sie ad hoc neu zu erstellen.

Was regelmäßig scheitert, ist der Ansatz einer "flexiblen Skriptdatei", bei dem jeder benutzerdefinierte Flags übergeben und hofft, dass sie den Anforderungen der Stores oder Tester entsprechen.

Kanäle fügen Kontrolle nach dem Versand des Binärs hinzu

Native builds are still coarse-grained. Once a release is in the store, changing web content inside a Capacitor app doesn’t always need a whole new binary.

Dort, wo Update-Kanäle nützlich werden, ist es, dass sie Teams ermöglichen, Web-Asset-Updates auf eine Untergruppe von Benutzern innerhalb eines installierten Produktionsbinärs zu targeten. Für Capacitor-Teams ist eine Option: Capgo, die signierte Web-Bundles an Zielkanäle veröffentlicht, damit Sie JavaScript, CSS, Kopien, Konfigurationen und Asset-Änderungen ohne das Neubauen der nativen Hülle jedes Mal pushen können.

Ein praktisches Muster sieht so aus:

• Binärbuild in CI/CD: Erstellen, signieren und verteilen Sie die native App.
• Kanalzuweisung: Benutzer oder Umgebungen auf Beta, Staging, Produktions- oder Kunden spezifische Streams zuordnen.
• Wahlweise Verteilung: Web-Änderungen an einer Gruppe senden, bevor sie breiter bekannt werden.
• Rückgängigmachungsweg: Ein Update ohne Wartezeit auf die Store-Bewertung zurücksetzen oder deaktivieren.

Wenn Sie dieses Modell noch nicht eingerichtet haben, hilft diese Anleitung auf Erstellen und löschen von Aktualisierungs-Kanälen in Capacitor die Mechanik zu verstehen.

Ein kurzer Demo hilft, wenn Sie noch keine Kanäle in Aktion gesehen haben:

Dies ist der strategische Wechsel, den viele mobile Teams benötigen. Build-Typen sind nicht nur Artefakte. Sie sind Steuerungspunkte. CI/CD steuert, wie Binärdateien erstellt werden. Kanäle steuern, wie post-installative Änderungen freigegeben werden.

Best Practices für einen modernen Build-Workflow

Ein vernünftiges Build-System ist opinioniert. Es lässt jeden Entwickler nicht improvisieren, wie Releases verhalten sich.

The strongest setups I’ve worked with share a few habits:

• Trennen Sie die Achsen klar: Flavor, Umgebung, Signiertziel und Verteilungsziel sollten nicht in einem vagen Label zusammengefasst werden.
• Lassen Sie CI-Produkte für das Team erstellen: local builds are for development, not for stakeholder trust.
• Test in bedingungen wie bei einer Veröffentlichung früh: QA- und Beta-Tester sollten das Verhalten sehen, das der App so nah wie möglich entspricht.
• Halten Sie Signierungsassets aus Laptops fern: Geheimnisse sollten in kontrollierten Infrastrukturen mit engem Zugriff sein.
• Benenne Artefakte so, dass Menschen sie lesen können: Wenn jemand in wenigen Sekunden nicht erkennen kann, wozu ein Datei dient, ist die Benennung schlecht.
• Legen Sie den Fokus auf die Förderung: Wenn ein Artefakt validiert wurde, bewege es stattdessen weiter durch den Workflow anstatt es manuell neu zu erstellen.
• Entwerfe eine Rückschaltung vor der Veröffentlichung: Die Rückschaltung im Speicher ist langsam und operativ schwer. Die Rückschaltung im Web-Schicht für Capacitor-Updates kann viel schneller sein, aber nur, wenn du die Kanäle und Politiken zuvor geplant hast.

Der größte Denkwechsel ist dieser: Frage nicht “Welche Build-Skript sollte ich ausführen?” Frage “Welches Risiko verwaltet man an dieser Stelle?” Diese Frage produziert bessere Build-Systeme.

Wenn dein Workflow diese Frage klar beantwortet, wird dein Release-Prozess einfacher zu bedienen, einfacher zu überprüfen und viel weniger von einem erfahrenen Ingenieur abhängig, der die richtige Formel kennt.

Wenn dein Team Capacitor-Apps versendet und eine enge Kontrolle über die Release-Workflows benötigt: Capgo ist wertvoll, wenn du diese Stack bewertest. Es handhabt gezielte Live-Updates für Web-Assets innerhalb von Capacitor-Apps, unterstützt signierte Bundles, kanalbasierte Rollouts und Rückschaltkontrollen, was es nützlich macht, wenn du schnellere Reparaturen benötigst, ohne deine native Build-Pipeline zu ersetzen.