Projekte anlegen

Ein Projekt ist in der Build Station ein Flutter-Ordner mit allem, was du zum Bauen brauchst: Flutter-Version, Store-IDs, Dart-Defines, Upload-Wege und die Presets. Liefert ihr dieselbe App an mehrere Kunden aus, legst du pro Kunde ein Projekt an.

Der Projekt-Assistent

Klick in der Seitenleiste auf + Projekt oder zieh einen Ordner aus dem Finder auf die Seitenleiste. Der Assistent hat zwei Schritte.

Schritt 1: Ordner wählen

Mit Ordner wählen … zeigst du auf den Flutter-Ordner. Die Station liest dann:

• pubspec.yaml und .fvmrc
• android/app/build.gradle bzw. build.gradle.kts
• ios/Runner.xcodeproj/project.pbxproj
• die Einstiegspunkte lib/main*.dart
• Shell-Scripts in tools/, scripts/ und bin/

Unter Erkannt steht, was sie gefunden hat: App-Name, Version, Flutter-Version, applicationId, Bundle-ID, Plattformen, Flavors, Entry-Points und Build-Scripts. Daraus entstehen Preset-Vorschläge. Das sind Vorschläge, keine Vorgabe: Du übernimmst sie einzeln oder lässt sie weg.

Findet die Station keine pubspec.yaml, sagt sie das. Liegt das Flutter-Projekt in einem Unterordner, wählst du besser diesen. Anlegen ist trotzdem möglich.

Schritt 2: Details

Alles ist vorausgefüllt und lässt sich ändern:

Feld	Bedeutung
Anzeigename	So heißt das Projekt in der Liste.
ID	Ordnername im Sammelordner, z. B. kunde-a.
Flutter-Version (fvm)	Leer heißt: die Version aus .fvmrc des Projekts.
Android applicationId, iOS Bundle-ID	Werden für Store-Uploads und Prüfungen gebraucht.
Store-Links	Play Console URL und App Store Connect URL, später ein Klick.
Default-Dart-Defines	Compile-Time-Konstanten für alle Presets dieses Projekts.
Default-Env	Prozess-Umgebung für die Toolchain, z. B. JAVA_HOME. Landet nicht in der App.

Projekt anlegen speichert. Du musst dafür keine JSON-Datei anfassen.

Projekt bearbeiten

Im Tab Build öffnet Projekt bearbeiten den Editor, alternativ Bearbeiten … im Kontextmenü der Projektliste. Neben den Feldern aus dem Assistenten findest du dort:

• Projektordner mit Ändern …, falls der Ordner umgezogen ist
• Git-Branch zum Koppeln an einen Branch (siehe unten)
• Web-Build committen (siehe Eigene Scripts und Web-Builds)
• Codemagic zum Verknüpfen mit einer Codemagic-App
• Upload mit Store-Upload einrichten und fastlane
• die Liste der Presets mit Bearbeiten, Duplizieren und Löschen

Unter Prüfung stehen Fehler und Hinweise. Solange ein Fehler drinsteht, etwa ein fehlender Ordner, bleibt Speichern gesperrt.

Einstellungen im Projekt mitgeben

Damit ein Projekt auf einem zweiten Mac nicht neu eingerichtet werden muss, kannst du seine Einstellungen in den Projektordner schreiben und einchecken.

… › Einstellungen in Projektordner exportieren … legt eine buildstation.json im Projektordner an. Darin stehen Presets, Env und Dart-Defines, Store-IDs, Upload-Modi und die Codemagic-Verknüpfung. Nicht darin stehen der Pfad und alle Zugangsdaten aus dem Schlüsselbund, Keystores und Zertifikate.

Werte in Env und Dart-Defines, deren Name nach Geheimnis aussieht (TOKEN, PASSWORD, KEY …), zeigt der Export unter Sieht nach Geheimnis aus an. Angehakte Werte bleiben in der Datei leer und werden nach dem Import nachgefragt.

Legst du auf dem anderen Mac ein Projekt für diesen Ordner an, erkennt der Assistent die Datei und bietet Exportierte Build-Einstellungen übernehmen an. Das Häkchen ist gesetzt, du kannst es abwählen.

Später holt … › Einstellungen aus Projektordner laden … einen neueren Stand in ein vorhandenes Projekt. Presets, Env, Dart-Defines, Upload- und Codemagic-Einstellungen werden dabei ersetzt, Zugangsdaten im Schlüsselbund bleiben unberührt.

Eine buildstation.json kann eigene Scripts enthalten, und die laufen ohne Sandbox. Schau in eine fremde Datei hinein, bevor du sie übernimmst. Siehe Einstellungen und Sicherheit.

Fehlende Zugangsdaten nachtragen

Nach dem Anlegen oder Importieren prüft die Station, was auf diesem Mac noch fehlt, und zeigt einen Dialog Zugangsdaten für „…“. Je nach Projekt sind das:

• das Codemagic-API-Token, wenn eine Codemagic-App verknüpft ist
• die Store-Zugangsdaten passend zum Upload-Modus: Service-Account, .p8, Partner-Center-Schlüssel oder die Service-Account-JSON für fastlane supply
• der Android-Keystore, wenn build.gradle eine key.properties liest
• das iOS-Distribution-Zertifikat des Teams aus der project.pbxproj
• Env- und Dart-Define-Werte, die beim Export leer geblieben sind

Jeden Punkt kannst du direkt im Dialog nachtragen oder über Einrichten … in die passende Einrichtung springen. Erneut prüfen aktualisiert die Liste, Später schließt sie. Dieselbe Prüfung gibt es jederzeit unter … › Zugangsdaten prüfen ….

Projekte als JSON weitergeben

… › Als JSON exportieren … speichert ein einzelnes Projekt als JSON-Datei. Über das Import-Symbol neben + Projekt liest die Station eine solche Datei wieder ein. Weil der Pfad je Rechner anders ist, fragt sie dabei nach dem Projektordner.

Ein Ordner, zwei Kunden

Liegt dieselbe App je Kunde in einem eigenen Branch, können zwei Projekte auf denselben Ordner zeigen und jeweils an einen Branch gekoppelt sein:

Projekt	Ordner	Branch
Kunde A	~/kunden/erp-ui	kunde-a
Kunde B	~/kunden/erp-ui	kunde-b

Das Feld heißt im Projekt-Editor Git-Branch. Über das Listen-Symbol daneben wählst du einen der lokal vorhandenen Branches. Leer lassen ist der Normalfall und ändert nichts.

Ist ein Branch gesetzt, wechselt die Station vor jedem Build dorthin, noch vor den Pre-Steps. So löst ein pub get nicht die Abhängigkeiten des falschen Stands auf. Der Wechsel steht im Log:

Git: Branch „kunde-b" → „kunde-a" …
Auf „kunde-a" gewechselt (a1b2c3d).

Drei Regeln gelten dabei, und sie sind Absicht:

• Ein unsauberer Working Tree bricht den Build ab. git checkout würde uncommittete Änderungen auf den anderen Branch mitnehmen. Committe oder verwirf sie vorher.
• Scheitert der Wechsel, bricht der Build ab. Sonst entstünde ein Artefakt mit dem Namen des einen und dem Code des anderen Kunden.
• Pro Ordner läuft nur eine Operation. Baut Kunde A, wartet Kunde B in der Warteschlange, auch wenn es zwei Projekte sind.

Nach einem Wechsel weist der Lauf darauf hin, dass sich die Abhängigkeiten unterscheiden können. Ein Pre-Step pub get im Preset erledigt das dauerhaft.

Nutzen zwei Projekte denselben Ordner, aber nur eines hat einen Branch, warnt der Projekt-Editor. Dasselbe gilt, wenn beide denselben Branch eingetragen haben.

Die Alternative: git worktree

git worktree add ../erp-ui-kunde-b kunde-b

Das legt für den Branch einen eigenen Ordner an, der sich das Repository mit dem ersten teilt. Dann sind es zwei Projekte mit zwei Pfaden, es wird nie gewechselt, und beide können parallel bauen. Wo der Platz da ist, ist das der ruhigere Weg. Die Kopplung ist für den Fall gedacht, dass es bei einem Ordner bleiben soll.

Git Pull und Push im Build-Tab

Ist der Projektordner ein Git-Repository, steht im Tab Build unter der Branch-Zeile eine Leiste für den Abgleich mit dem Remote. Sie zeigt, ob der Branch Synchron mit seinem Upstream ist, wie viele Commits vor oder zurück er liegt, oder dass es noch Kein Upstream gibt.

• Pull führt git pull --ff-only aus. Es holt nur dann neue Commits, wenn das ohne Merge geht. In Klammern steht, wie viele Commits warten.
• Commit & Push öffnet einen Dialog mit den geänderten Dateien, einer vorgeschlagenen Commit-Nachricht und dem Schalter Danach pushen. Gibt es nichts zu committen, aber ungepushte Commits, heißt der Knopf Push.
• Das Pfeilsymbol Remote prüfen (git fetch) holt den aktuellen Stand des Remote.

Das ist praktisch für alles, was die Station selbst im Projekt ändert: die Version in der pubspec.yaml, einen Flutter-Hotfix in der .fvmrc oder eine automatische Reparatur. Solange im Ordner ein Build läuft, sind die Knöpfe gesperrt.