Vor dem Release kennt man das Bild: jemand ruft in Slack „wer klickt TestFlight“, ein anderer verbindet sich manuell per SSHxcodebuild, ein Dritter sagt „bei mir geht's“. Cloud-Mac löst Hardware – bleibt alles manuell,„läuft auf meinem Rechner“ bleibt Glückssache. Nach OpenClaw auf Zutcloud-Dediziert-Knoten: Ziel klar –Orchestrierung + fester Knoten, Trigger, Build, Signaturprüfung und Receipt in eine prüfbare Kette.
Von „manueller Release“ zu „Ketten-Release“
Vor Automatisierung: mittleres iOS-Team ~40 Min pro Release nur für „Umgebung prüfen“:
| Manueller Schritt | Versteckte Kosten | Nach Automatisierung |
|---|---|---|
| Xcode / Zertifikatsversion prüfen | Mündlich, leicht vergessen | Image-Version ins Pipeline-Manifest |
| Lokales Archive-Probelbuild | Jede Umgebung anders | Fester DerivedData-Pfad auf Dediziert-Knoten |
| TestFlight-Upload | Wer Zeit hat, macht's | Signatur-Stage triggert altool / Transporter automatisch |
| QA benachrichtigen | Build-Nummer passt nicht | Receipt-Webhook mit commit + Artefakt-Hash |
Fünfstufige Pre-Release-Kette
Wir teilen Pre-Release-Checks in fünf unabhängig wiederholbare Phasen. Jede Phase meldet strukturiertes JSON an die Orchestrierung, nicht nur stderr:
- Trigger— PR-Merge, Tag-Push oder geplanter Nacht-Build; protokolliert
trigger_idund Branch - Freeze (Umgebung einfrieren)— prüft Knoten-Image, Xcode-Version,
openclaw.yamlRegion und Cache-Root in - Build—
xcodebuild/fastlane; liefert .xcarchive und Unit-Test-Bericht - Gate— Static-Analysis-Schwellen, Testabdeckung, Paketgröße WoW; blockiert Downstream bei Fail
- Receipt— Artefakt-Hash, Knoten-ID, Dauer an Webhook / Read-only-Kanal
Beispiel Orchestrierungs-Konfiguration
Vereinfachtes Beispiel: Zutcloud-Dediziert-Knoten als OpenClaw-Runner registrieren und Metadaten beim Trigger injizieren (Feldnamen je nach CI):
name: pre-release-mac on: push: tags: ['v*'] jobs: build-on-cloud-mac: runs-on: [self-hosted, macOS, zutcloud-ap-northeast] steps: - run: openclaw daemon health --json - run: | export OPENCLAW_NODE_ID="vn-apne1-m4-01" export ARTIFACT_ROOT="/Volumes/artifacts/ap-northeast-1" ./scripts/ci-build.sh - run: openclaw receipt publish \ --trigger-id "${{ github.run_id }}" \ --sha "${{ github.sha }}" \ --artifact-hash "$(shasum -a 256 dist/*.ipa)"
Drei Details beachten:Health-Check als erster Schritt, damit bei Daemon-Ausfall kein halbstündiger Build läuft;Umgebungsvariablen im Shell-Block explizit exportieren, nicht SSH-Login-profile vertrauen;Receipt als eigener Schritt, selbst wenn TestFlight-Upload scheitert, bleibt „Build erfolgreich“ belegt.
Dediziert-Knoten: warum kein Shared Runner
Shared Mac CI wirkt günstig, für Pre-Release-Checks drei harte Nachteile: Cache unkontrollierbar, Zertifikatsisolation schwierig, Wartezeit unvorhersehbar. Dediziert-Knoten binden DerivedData, Pods-Cache und Signatur-Keychain an eine physische Maschine –Ketten-Determinismusweit über „jedes Mal zufällige Maschine“.
| Dimension | Shared Runner | Zutcloud Dediziert + OpenClaw |
|---|---|---|
| Cache | Nach Job gelöscht | Volume-Snapshot, an Xcode-Version gebunden |
| Zertifikat | Multi-Tenant-Risiko | Single-Tenant-Keychain, offline Signatur-Maschine möglich |
| Audit | Logs verstreut | Trigger → Knoten → Artefaktzeichenfolge bis zum Ende |
| Warteschlange | Der Spitzenwert kann stündlich sein | Exklusive Rechenleistung, Nachtbau kann reserviert werden |
Rücksendebelege und Prüfbarkeit
Bei „Auditable“ geht es nicht um die Speicherung eines riesigen Log-Tarballs, sondern um die Beantwortung von fünf Fragen für jede Veröffentlichung:
- Wer hat es ausgelöst? (PR-Autor / Tag / geplante Aufgabe)
- Auf welchem Knoten und in welchem Bereich wurde es kompiliert? (
node_id+region) - Was soll Xcode mit zwischengespeicherten Snapshots verwenden? (Image-Version + Cache-Root-Pfad)
- Was ist der Artefakt-Hash? (IPA/dSYM reproduzierbar)
- Welche Phase ist gescheitert? (Einfrieren/Build/Gate/Upload)
Wir senden Belege an den schreibgeschützten Slack-Kanal des Teams (oder einen gleichwertigen Kanal). Das Format ist auf einen einzeiligen JSON-Zusammenfassungs- und Detaillink festgelegt. Die Qualitätssicherung muss nicht mehr fragen: „Welcher Build ist das?“ - Build-Nummer, Commit und Hash sind in der Nachricht bereits abgeglichen.
{
"trigger_id": "gh-1849201",
"sha": "a1b2c3d",
"node_id": "vn-apne1-m4-01",
"region": "ap-northeast-1",
"xcode": "16.2",
"stages": {
"freeze": "ok",
"build": "ok",
"gate": "ok",
"receipt": "ok"
},
"artifact_sha256": "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08"
}
Fortschrittliche Umsetzungsvorschläge
Es ist nicht erforderlich, alle lokalen Archive in der ersten Woche herunterzufahren. Ein sicherer Weg ist:
Woche 2: Öffnen Sie die Gate-Phase und blockieren Sie die Zusammenführung, wenn der Test fehlschlägt.
Woche 3: Tag-Releases durchlaufen die gesamte fünfstufige Kette; Das lokale Archiv wird zu einem Ausnahmepfad.
ZusammenarbeitenLeitfaden zur Zonen- und FestplattenauswahlGemeinsam verwenden: Knotenmetadaten werden in der ersten Woche gepaart und es erfolgt keine Überarbeitung von „Der Link ist verbunden, aber der Produktpfad ist falsch“, wenn die Version in der dritten Woche geschnitten wird.
Was tun, wenn Sie scheitern?
Der Wert automatisierter Links liegt zur Hälfte im Erfolg und zur Hälfte darinFehler können lokalisiert werden. Wir pflegen ein einfaches Spielbuch:
- Einfrieren ist fehlgeschlagen– Bilddrift oder openclaw.yaml stimmt nicht mit dem Knoten überein → Frieren Sie den Knoten ein und setzen Sie das Bild-Tag zurück
- Build fehlgeschlagen– Code- oder Abhängigkeitsprobleme → F&E und Codereparatur, unabhängig von der Infrastruktur
- Tor versagt– Abdeckungs- oder Paketvolumenregression → Blockfreigabe, Genehmigung muss explizit ausgenommen werden
- Der Empfang ist fehlgeschlagen– Der Build war erfolgreich, aber die Benachrichtigung/das Hochladen ist fehlgeschlagen → Sie können die Empfangsphase erneut ausführen, ohne sie vollständig neu programmieren zu müssen.
Nach der Aufteilung der Phasen werden die Kosten für die „Neuausführung“ von einer Stunde für die vollständige Kompilierung auf einige Minuten für den Empfang oder den erneuten Gate-Versuch reduziert – dies ist die von der Orchestrierungsschicht eingesparte Echtzeit.
Führen Sie den gesamten Link auf einem Mac in der Cloud aus
OpenClaw-Daemon, Integritätsprüfung und Pipeline-Skripte können rund um die Uhr unbeaufsichtigt auf Zutcloud Mac mini M4 ausgeführt werden. Der Standby-Stromverbrauch von ca. 4 W ist für den Einsatz als residenter CI-Knoten geeignet; Dank der exklusiven Rechenleistung kann DerivedData eins zu eins mit Zertifikatsrichtlinien und Orchestrierungsschichtkonfigurationen korrespondieren.
Wenn Sie die Vorabprüfung von „menschlicher Klick-Button“ auf „Empfang bei Auslösung“ ändern, verlagert sich die Teamdiskussion von „Wessen Umgebung hat ein Problem“ zu „Welche Gate-Regel muss angepasst werden“ – das ist die Gewissheit, die Cloud-Mac bringen sollte.
Sind Sie bereit, den ersten Pre-Release-Link zu erstellen?Beginnen Sie mit einem exklusiven Knoten für den asiatisch-pazifischen Raum oder den US-Westen und erstellen Sie über Nacht einen Cron——Mac-Cloud-Hosting-Tarife ansehen, führen Sie OpenClaw auf fester Hardware aus.