Avant release, scène familière : quelqu'un crie sur Slack « qui clique TestFlight », un autre SSH manuellementxcodebuild, un troisième « chez moi ça passe ». Mac cloud règle le hardware — si checks manuels,« ça marche chez moi » reste une loterie. OpenClaw sur nœuds dédiés Zutcloud : objectif clair —orchestration + nœud fixe, trigger, build, vérif signature et receipt dans une chaîne auditable.
De « release manuelle » à « release en chaîne »
Avant automatisation : équipe iOS moyenne ~40 min par release juste pour « confirmer l'environnement » :
| Étape manuelle | Coût caché | Après automatisation |
|---|---|---|
| Confirmer versions Xcode / certificats | Sync oral, oublis fréquents | Version image dans manifest pipeline |
| Archive test local | Environnement différent par personne | Chemin DerivedData fixe sur nœud dédié |
| Upload TestFlight | Qui est libre le fait | Stage signature déclenche altool / Transporter auto |
| Notifier QA | Numéro build incohérent | Webhook receipt avec commit + hash artefact |
Chaîne pré-release en cinq étapes
Nous découpons les checks pré-release en cinq phases rejouables. Chaque phase renvoie du JSON structuré à l'orchestration, pas seulement stderr :
- Trigger— merge PR, push tag ou build nocturne planifié ; enregistre
trigger_idet branche - Freeze (gel environnement)— vérifie image nœud, version Xcode,
openclaw.yamlregion et root cache dans - Build—
xcodebuild/fastlane; produit .xcarchive et rapport tests unitaires - Gate— seuils analyse statique, couverture tests, taille paquet WoW ; bloque aval si échec
- Receipt— hash artefact, ID nœud, durée vers webhook / canal read-only
Exemple configuration orchestration
Exemple simplifié : enregistrer nœud dédié Zutcloud comme runner OpenClaw et injecter métadonnées au trigger (noms champs selon 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)"
Trois détails :health check en première étape, éviter compile 30 min si daemon down ;exporter explicitement variables d'environnement dans bloc shell, ne pas compter sur profile SSH ;receipt en étape séparée, même si upload TestFlight échoue, preuve « build réussi » conservée.
Nœud dédié : pourquoi pas runner mutualisé
CI Mac mutualisé semble bon marché, trois faiblesses pour pré-release : cache incontrôlable, isolation certificats difficile, file d'attente imprévisible. Nœud dédié lie DerivedData, cache Pods et trousseau signature à une machine physique —déterminisme de chaînebien au-delà de « machine aléatoire à chaque fois ».
| Dimension | Runner mutualisé | Zutcloud dédié + OpenClaw |
|---|---|---|
| Cache | Effacé fin de job | Snapshot volume, lié version Xcode |
| Certificat | Risque multi-tenant | Trousseau single-tenant, machine signature offline possible |
| Audit | Logs dispersés | déclencheur → nœud → chaîne d'artefact jusqu'à la fin |
| file d'attente | Le pic peut être horaire | Puissance de calcul exclusive, la construction de nuit peut être réservée |
Accusés de réception et auditabilité
"Auditable" ne consiste pas à stocker une énorme archive de journaux, mais à répondre à cinq questions pour chaque version :
- Qui l'a déclenché ? (Auteur PR / tag / tâche planifiée)
- Sur quel nœud et dans quelle zone a-t-il été compilé ? (
node_id+region) - Que faut-il utiliser Xcode avec les instantanés mis en cache ? (Version de l'image + chemin racine du cache)
- Qu'est-ce que le hachage de l'artefact ? (IPA/dSYM reproductible)
- Quelle étape a échoué ? (geler/construire/porte/télécharger)
Nous transmettons les reçus vers le canal Slack en lecture seule de l'équipe (ou équivalent), et le format est fixé comme un résumé JSON sur une seule ligne + un lien de détails. Le contrôle qualité n'a plus besoin de demander « de quelle version s'agit-il ? - le numéro de build, le commit et le hachage sont déjà alignés dans le message.
{
"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"
}
Suggestions de mise en œuvre progressive
Il n’est pas nécessaire de fermer toutes les archives locales au cours de la première semaine. Un chemin plus sûr est :
Semaine 2: Ouvrez l'étage de porte et bloquez la fusion si le test échoue.
Semaine 3: les versions de balises parcourent la chaîne complète en cinq étapes ; L'archive locale devient un chemin d'exception.
CoopérerGuide de sélection de zones et de disquesUtiliser ensemble : les métadonnées du nœud sont appariées au cours de la première semaine, et il n'y aura aucune refonte de "le lien est connecté mais le chemin du produit est erroné" lorsque la version est coupée au cours de la troisième semaine.
Que faire en cas d'échec
La valeur des liens automatisés réside pour moitié dans le succès et pour moitié dansLa panne peut être localisée. Nous maintenons un playbook simple :
- échec du gel— La dérive de l'image ou openclaw.yaml est incohérente avec le nœud → Geler le nœud et restaurer la balise d'image
- échec de la construction— Problèmes de code ou de dépendances → R&D et réparation de code, quelle que soit l'infrastructure
- porte échouée— Régression de la couverture ou du volume du colis → libération en bloc, nécessité d'exempter explicitement l'approbation
- reçu échoué— La construction a réussi mais la notification/téléchargement a échoué → Vous pouvez réexécuter l'étape de réception sans avoir à la reprogrammer complètement.
Après avoir divisé les étapes, le coût de « réexécution » est réduit d'une heure de compilation complète à quelques minutes de réception ou de nouvelle tentative de porte - c'est le temps réel économisé par la couche d'orchestration.
Exécutez l'intégralité du lien sur un Mac dans le cloud
Le démon OpenClaw, les scripts de vérification de l'état et de pipeline peuvent s'exécuter sans surveillance 7×24 sur Zutcloud Mac mini M4. La consommation électrique en veille d'environ 4 W convient à une utilisation en tant que nœud CI résident ; la puissance de calcul exclusive permet à DerivedData de correspondre individuellement aux politiques de certificat et aux configurations de la couche d'orchestration.
Lorsque vous modifiez la vérification préalable à la publication de « bouton de clic humain » à « reçu lors du déclenchement », la discussion d'équipe passera de « quel environnement a un problème » à « quelle règle de porte doit être ajustée » - c'est la certitude que le cloud Mac devrait apporter.
Prêt à créer le premier lien de pré-version ?Commencez avec un nœud exclusif pour l'Asie-Pacifique ou l'Ouest des États-Unis + créez cron du jour au lendemain——Voir offres Mac cloud, exécutez OpenClaw sur du matériel fixe.