Pour les équipes Asie-Pacifique et Amérique du Nord

Du premier accès à la livraison de l’app

Votre machine est prête : reprenez à l’étape qui bloque. Vérifiez séparément la connexion, les outils, la signature et le pipeline pour rendre chaque build réussi reproductible.

Louer un Mac cloud Voir les instances dans la console

Pour l’adresse, le port, le nom d’utilisateur et l’état de livraison, consultez les détails de l’instance dans la console. Remplacez les variables d’environnement des commandes par vos propres valeurs : aucun identifiant réel n’est fourni.

01 · Se connecter à la machine

Vérifiez d’abord le point d’accès, puis la connexion

SSH sert à la ligne de commande et à l’automatisation ; VNC, à l’interface graphique. Les deux donnent accès à la même machine physique dédiée, mais leurs paramètres de connexion doivent être vérifiés séparément.

SSH : vérifiez chaque paramètre de connexion

Ouvrez l’instance correspondante dans la console et relevez l’adresse de l’hôte, le port SSH et le nom d’utilisateur. Vérifiez d’abord le chemin de votre clé privée, puis lancez la connexion. N’indiquez pas le port VNC dans la commande SSH.

chmod 600 "$SSH_KEY"
ssh -i "$SSH_KEY" -p "$SSH_PORT" "$NODE_USER@$NODE_HOST"

Lors de la première connexion, vérifiez l’empreinte de l’hôte. Si vous ne pouvez pas la confirmer, ouvrez un ticket avant de poursuivre et ne désactivez pas la vérification de l’hôte. En cas de délai dépassé, vérifiez votre réseau local et l’accessibilité du port. En cas de refus d’accès, vérifiez le nom d’utilisateur, la clé et la clé publique configurée sur l’instance.

Après une réinstallation ou un changement de machine, l’empreinte peut changer. Mettez à jour votre enregistrement local uniquement après avoir confirmé la modification de l’instance.

VNC : réservez le bureau aux opérations interactives

Connectez-vous à l’aide des informations de bureau à distance fournies dans la console et vérifiez l’adresse, le port et le mot de passe. Lors de votre première connexion, définissez votre propre mot de passe d’accès au lieu de partager les mêmes identifiants sur le long terme.

Le bureau est pratique pour configurer Xcode, vérifier le trousseau et surveiller le simulateur. Pour les builds continus, privilégiez SSH ou un runner. Si SSH fonctionne mais pas le bureau, relevez le message d’erreur du client et l’état de l’instance, puis examinez la connexion au bureau à distance sans redémarrer la machine à répétition.

Pour accéder à VNC via un tunnel SSH, configurez la redirection avec le port VNC réellement utilisé, puis connectez votre client au port local :

ssh -N -L 5901:127.0.0.1:"$VNC_PORT" \
  -p "$SSH_PORT" "$NODE_USER@$NODE_HOST"

Le tunnel doit rester actif. Consultez la configuration de l’instance et les règles d’accès de votre équipe pour savoir s’il faut l’utiliser et quel port choisir.

Choisissez le nœud selon le lieu de travail, pas selon celui du projet

Les 5 nœuds sont situés à Singapour, Tokyo, Séoul, Hong Kong et sur la côte Est des États-Unis. Pour un bureau interactif, privilégiez la proximité des principaux utilisateurs. Pour les builds automatisés, tenez aussi compte des accès au dépôt et aux dépendances. Les équipes réparties sur plusieurs régions peuvent installer des machines de build à proximité et répartir les tâches avec des labels runner explicites, sans obliger tout le monde à utiliser le même bureau à distance.

Pour comparer les nœuds, utilisez le même client, le même réseau et le même créneau horaire pour mesurer le temps aller-retour, le clonage du dépôt et un build complet. La latence réseau ne correspond pas au temps de compilation : ne comparez pas directement des résultats obtenus dans des conditions réseau différentes.

02 · Stabiliser les outils

Associez chaque branche à une version précise de Xcode

Notez les versions avant de migrer la signature. Le fait qu’un build fonctionne sur le bureau ne garantit pas que la session utilisateur du runner soit prête.

Gardez plusieurs versions sans qu’elles se remplacent

Attribuez un nom distinct à chaque version de Xcode et placez-les dans le dossier Applications. Stable et Next sont des noms d’applications personnalisés : remplacez-les par les noms réellement utilisés sur la machine avant d’exécuter les commandes. Lancez chaque version une première fois, acceptez la licence et installez les composants de plateforme nécessaires avant de l’intégrer au pipeline.

xcode-select -p
xcodebuild -version
xcrun --sdk iphoneos --show-sdk-version

sudo xcode-select --switch \
  /Applications/Xcode-Stable.app/Contents/Developer

Un changement global affecte les tâches qui ne spécifient pas explicitement leur chaîne d’outils. Pour exécuter plusieurs branches en parallèle, définissez plutôt la variable d’environnement dans chaque tâche afin qu’un autre pipeline ne change pas la version par défaut en cours d’utilisation.

export DEVELOPER_DIR=/Applications/Xcode-Next.app/Contents/Developer
xcodebuild -version

Vérifiez ensemble certificats, clés privées et profils

Dans le compte macOS qui exécutera réellement le build, importez le certificat de signature et la clé privée correspondante, puis installez le profil de provisioning selon les réglages de signature de la version actuelle de Xcode. Sans clé privée, le certificat seul ne permet pas de signer le code.

security find-identity -v -p codesigning
xcodebuild -list -workspace App.xcworkspace

Vérifiez l’identifiant d’équipe du projet, le Bundle Identifier, le mode de signature et les cibles du profil de provisioning. Effectuez d’abord un archive manuel avec le même utilisateur, puis lancez la même commande en CI pour distinguer les problèmes de configuration du projet de ceux liés aux droits de la session runner.

Pour l’automatisation, privilégiez un trousseau dédié et une procédure contrôlée d’injection des clés. Vérifiez que la session non interactive peut accéder à l’identité de signature. Ne stockez pas le mot de passe du trousseau, celui d’export du certificat ni la clé privée dans le dépôt, et ne les affichez pas dans les journaux de build.

Conservez un rapport de build reproductible

L’exemple ci-dessous utilise un espace de travail et un scheme partagé. Remplacez le nom du projet, le scheme et la configuration d’export. Préparez cette dernière en fonction des exigences de signature et de distribution du projet. Consignez le code de sortie, la version des outils et le chemin des artefacts, et pas seulement le message de réussite.

xcodebuild archive \
  -workspace App.xcworkspace \
  -scheme App \
  -configuration Release \
  -destination 'generic/platform=iOS' \
  -archivePath "$HOME/builds/App.xcarchive"

xcodebuild -exportArchive \
  -archivePath "$HOME/builds/App.xcarchive" \
  -exportPath "$HOME/builds/export" \
  -exportOptionsPlist ExportOptions.plist

03 · Mettre en place la CI

Exécutez les tâches avec un compte macOS dédié

Le fait qu’une machine soit louée à un seul client ne garantit pas l’absence d’interférences entre les tâches. Votre équipe doit également définir le compte de build, les répertoires et les règles de file d’attente.

GitHub Actions : enregistrez le runner avant de l’installer comme service

Dans les paramètres du runner du dépôt ou de l’organisation, téléchargez le paquet adapté à Apple Silicon et récupérez les commandes d’enregistrement. Décompressez le paquet dans un répertoire dédié. Utilisez le jeton temporaire fourni sur cette page pour enregistrer le runner auprès du dépôt ou de l’organisation concerné, sans le stocker dans un script.

./config.sh \
  --url "$RUNNER_URL" \
  --token "$RUNNER_TOKEN" \
  --labels pushmac,macos,arm64

./svc.sh install
./svc.sh start
./svc.sh status

Les valeurs de runs-on dans le workflow doivent correspondre aux labels du runner. Commencez par une tâche de test sans signature pour vérifier la chaîne d’outils, le répertoire de travail et les autorisations, puis ajoutez les tâches de publication. Réservez les runners qui disposent des ressources de signature au code de confiance.

Exécutez les commandes du service depuis le répertoire d’installation du runner et utilisez le même compte pour les opérations et le service.

GitLab Runner : définissez l’exécuteur et le répertoire de travail

Installez un runner compatible en suivant la documentation de votre instance GitLab, puis enregistrez-le avec les informations d’authentification fournies par cette instance. Pour compiler des projets macOS de façon native, vous pouvez choisir l’exécuteur shell. Les tâches s’exécutent alors avec les droits du compte local : limitez les projets et branches autorisés à les déclencher.

mkdir -p "$HOME/ci"
gitlab-runner register
gitlab-runner install --working-directory "$HOME/ci"
gitlab-runner start
gitlab-runner status

Suivez les instructions pour renseigner l’adresse de l’instance de votre équipe, le jeton, les labels et l’exécuteur. Le fichier de configuration peut contenir des informations d’authentification : restreignez-en l’accès. Conservez les identifiants des tâches et les traces d’erreur dans les journaux sans y afficher de variables d’environnement secrètes.

Les paramètres d’installation doivent correspondre à la version du runner installée. Consultez d’abord l’aide disponible sur la machine avant de lancer la commande.

Vérifiez la première tâche après un redémarrage

Les services macOS exécutés au niveau utilisateur dépendent généralement d’une session ouverte. L’installation du service ne garantit pas l’exécution de tâches de signature en l’absence de connexion. Vérifiez le type de service launchd utilisé par le runner, les conditions de connexion et la disponibilité du trousseau. Ne contournez pas les règles d’accès de votre équipe pour activer le démarrage automatique.

À un moment où vous maîtrisez les opérations, vérifiez l’état du service après un redémarrage et lancez un build complet. Pour utiliser les dépendances verrouillées par le projet avec Fastlane, exécutez par exemple bundle exec fastlane ios build, en remplaçant le nom du lane par celui défini dans le projet. Lors du passage de relais entre fuseaux horaires, précisez le nombre de tâches simultanées et les règles de file d’attente pour éviter que deux archives écrivent dans le même répertoire d’artefacts.

04 · Conserver le travail réutilisable

Analysez les temps de build avant d’étendre le stockage

Mesurez séparément la résolution des dépendances, la compilation, la signature et l’export. Pour évaluer le cache, comparez un build à froid et un build à chaud avec le même commit et la même chaîne d’outils.

Organisez le cache par projet et chaîne d’outils

Une machine dédiée peut conserver DerivedData, les paquets téléchargés par SPM et le cache CocoaPods pendant sa période de location. Ne faites pas écrire toutes les branches dans le même répertoire sans distinction : séparez les chemins par projet, chaîne d’outils et type de tâche, et conservez les fichiers de verrouillage des dépendances.

xcodebuild archive \
  -workspace App.xcworkspace \
  -scheme App \
  -destination 'generic/platform=iOS' \
  -derivedDataPath "$HOME/ci-cache/App/stable/DerivedData" \
  -clonedSourcePackagesDirPath "$HOME/ci-cache/App/stable/SPM" \
  -archivePath "$HOME/builds/App.xcarchive"

Pour les projets Flutter et React Native, veillez aussi à aligner les versions des outils et l’état des dépendances iOS verrouillées. En cas d’anomalie, conservez d’abord les journaux d’échec, puis nettoyez le cache concerné. Tout supprimer à chaque build annule généralement les gains du cache à chaud.

Traitez séparément le stockage et la mémoire

Le Push M4 S associe M4, 16GB de mémoire et 256GB de stockage : il convient à la CI quotidienne d’une seule app. Le Push M4 L associe M4, 24GB et 512GB : il convient aux besoins mémoire plus importants et aux builds avec plusieurs targets. Pour évaluer le parallélisme, fiez-vous aux pics de consommation mesurés sur votre projet.

+1TB SSD convient si les caches de dépendances, plusieurs chaînes d’outils et les anciens artefacts remplissent progressivement le disque système. +2TB SSD est adapté aux workflows qui doivent conserver davantage de caches de projets et d’archives. Une option de stockage supplémentaire n’augmente pas la mémoire unifiée et ne garantit pas une compilation plus rapide.

df -h
du -sh "$HOME/ci-cache" "$HOME/builds"

Repérez le point de montage avant de déplacer le cache et de modifier les variables du pipeline. L’espace supplémentaire ne remplace pas une sauvegarde : archivez les builds, fichiers de symboles et configurations importantes dans des copies distinctes, conformément aux règles de votre équipe.

Voir les configurations et les options

05 · Compte et période de location

Anticipez le renouvellement avant les mises en production

La période de facturation, le nœud et l’état du paiement affichés dans la console font foi. Lorsque vous ouvrez un ticket, indiquez le numéro de commande. N’envoyez ni mot de passe, ni clé privée, ni numéro complet de carte bancaire.

Location à la journée et périodes de renouvellement

La facturation est disponible à la journée, à la semaine, au mois ou au trimestre. Le Push M4 S coûte $19.2/jour, $51.8/semaine, $95.9/mois ou $260.8/trimestre ; le Push M4 L, $39.7/jour, $107.2/semaine, $198.5/mois ou $539.9/trimestre. Consultez dans la console la date d’expiration de l’instance, l’option de renouvellement et les périodes disponibles. Ne calculez pas le prix d’une autre période en multipliant le tarif journalier.

Avant une mise en production, vérifiez que la période de location couvre les builds et la validation. Pour modifier la période, consultez les options proposées dans la console et le montant réel de la facture. Ne supposez pas qu’un paiement existant sera automatiquement converti vers une autre période.

Préparez la migration avant de changer de nœud

Changer de nœud implique un nouveau point d’accès réseau et un nouvel environnement machine ; ce n’est pas un simple changement de région. Ouvrez d’abord un ticket dans la console pour confirmer la procédure, puis sauvegardez le code, les ressources de signature, la configuration du runner et les artefacts nécessaires. Ne partez pas du principe que les fichiers locaux, le cache ou les informations de connexion seront transférés automatiquement.

Après la migration, vérifiez à nouveau l’empreinte de l’hôte, les labels du runner et les autorisations de signature. Validez un build avant d’arrêter la distribution des tâches vers l’ancien environnement.

Moyens de paiement et facturation en dollars

Les seuls moyens de paiement acceptés sont USDT-TRC20 et les cartes Visa, Mastercard ou Amex, traitées par Stripe. Tous les paiements sont effectués en dollars américains (USD). La disponibilité effective des moyens de paiement dépend des options renvoyées par le serveur. Pour un paiement on-chain, suivez les informations de réseau, de destinataire et de montant de la commande en cours ; ne réutilisez pas celles d’une ancienne commande.

Après le paiement, vérifiez d’abord l’état de la commande. Pour toute vérification, communiquez par ticket le numéro de commande, l’heure du paiement et le hash de transaction ou la référence de paiement. Ne payez pas une seconde fois pour actualiser l’état.

Disponibilité toute l’année et sauvegarde des projets

Les machines physiques fonctionnent 365 jours par an. Le centre de données assure l’alimentation électrique, le réseau et le refroidissement, pour un fonctionnement continu toute l’année. Cela ne remplace pas les sauvegardes de vos projets et ne garantit pas que la connexion de votre poste restera ininterrompue. Si une session à distance est interrompue, vérifiez d’abord l’état de l’instance et essayez l’autre mode de connexion avant de conclure à un problème de machine.

À la fin de la période de location, la machine est effacée avant d’être attribuée à un autre client. Avant de résilier, exportez le code, les artefacts et les configurations nécessaires, désenregistrez le runner et révoquez les jetons d’accès associés. Ne conservez pas vos seules archives sur l’instance.

Continuez à optimiser votre pipeline de build

Ce guide pour les opérations, nos articles pour approfondir

Cette page traite des opérations courantes. Pour comprendre les migrations, la conception du cache et la coordination entre fuseaux horaires, consultez nos articles, qui en détaillent le contexte.

Articles techniques PushMac

Choisissez un sujet parmi les articles publiés pour consulter les étapes détaillées et les conditions d’utilisation. Avant de migrer la chaîne d’outils ou de modifier les répertoires de cache, consignez la configuration existante, prévoyez une procédure de retour arrière et validez chaque changement séparément.

Les commandes de ce guide illustrent les opérations. Les conseils des articles doivent également être adaptés à la structure de votre dépôt, à votre politique de signature et aux autorisations de votre équipe.

Lire les articles techniques

Joignez au ticket un rapport de build vérifiable

Quand des collègues d’Asie-Pacifique et d’Amérique du Nord se relaient pour résoudre un problème, préciser l’heure et le nœud aide davantage que de signaler simplement que « la connexion ne fonctionne pas ».

01
Identifier l’instance

Indiquez le numéro de commande ou d’instance, le nœud utilisé, l’heure et le fuseau horaire. Si les membres de l’équipe utilisent des réseaux différents, précisez le lieu de connexion de chacun.
02
Joindre l’erreur

Ajoutez le message d’erreur du client, la commande de build, le code de sortie, la version de Xcode et les dernières lignes de journal pertinentes. Supprimez les informations confidentielles des captures d’écran et des textes avant de les envoyer.
03
Indiquer les vérifications déjà effectuées

Précisez si SSH et VNC fonctionnent chacun de leur côté, si le problème peut être reproduit et quelles configurations ont été modifiées récemment. Cela évitera à la personne suivante de refaire les mêmes vérifications.

Transmettez le compte rendu à l’assistance

Connectez-vous à la console pour ouvrir un ticket et obtenir de l’aide sur une instance ou une commande. Si vous ne pouvez pas vous connecter, envoyez un e-mail à support@pushmac.comen indiquant l’adresse e-mail de votre compte et la nature du problème.

Se connecter et ouvrir un ticket Louer un Mac cloud