Votre Mac mini est hébergé en centre de données ; votre équipe gère le code et les certificats. La machine est louée à un seul client : ce n’est pas une machine virtuelle.
Confiez vos compilations Xcode nocturnes à un nœud physique disponible 365 jours par an et intégrez les clés de connexion, identifiants de build et exports de fin de location à vos procédures d’équipe. Le matériel dédié isole les ressources ; les accès quotidiens doivent toujours être attribués clairement.
Location à la journée dès $19.2/jour. Avant la mise en service, désignez un responsable de l’équipement, les membres autorisés et la méthode d’export des données.
Avec une machine physique dédiée, la séparation entre clients s’applique à l’équipement tout entier. Vous ne partagez ni les ressources d’exécution d’un même hôte ni le stockage de la machine avec d’autres clients.
Vous recevez un Mac mini physique, et non une machine virtuelle découpée sur un hôte. La puce, la mémoire unifiée et le stockage local sont réservés aux charges de travail du client pendant la location.
Limite : la machine n’est pas partagée entre clients.
Dépôts, DerivedData, caches de dépendances et artefacts de build peuvent rester sur la machine pendant la location. Votre équipe définit l’organisation des dossiers et les membres autorisés à les lire ou à les modifier.
Limite : les permissions des fichiers restent à configurer au sein de votre équipe.
Une machine dédiée ne signifie pas des ressources distinctes pour chaque tâche. Plusieurs runners, simulateurs et archives exécutés simultanément utilisent toujours la mémoire, le CPU et le disque de la même machine.
Conseil : définissez le niveau de concurrence des builds et une file de tâches.
Dès réception des identifiants SSH / VNC, définissez vos règles d’accès avant d’importer le code source et les certificats. Lorsque des membres d’Asie-Pacifique et d’Amérique du Nord se relaient, ne faites surtout pas d’un mot de passe permanent votre procédure de passation.
Enregistrez la clé publique de chaque membre autorisé à se connecter ; ne transmettez jamais de clé privée dans les conversations. Au départ d’un membre, supprimez son autorisation. Gérez séparément les clés CI et celles utilisées pour les connexions interactives personnelles.
Avant de désactiver la connexion par mot de passe, gardez la session actuelle ouverte et vérifiez la connexion par clé dans une deuxième session. Vous éviterez ainsi de bloquer toute l’équipe hors de la machine.
Après la première connexion, choisissez un mot de passe VNC propre à l’équipe. Ne réutilisez ni celui du portail ni les identifiants de vos dépôts. Changez-le en cas de changement d’équipe ou de fuite possible.
Utilisez l’interface graphique pour les opérations nécessitant une validation humaine ; privilégiez SSH et les runners pour les builds automatisés. Après utilisation, fermez les outils sensibles et ne laissez pas de mot de passe d’export visible à l’écran.
Vérifiez les réglages de partage de macOS. Désactivez le partage de fichiers, les événements Apple à distance et les autres services inutiles au projet ; conservez uniquement les accès réellement utilisés, comme la connexion à distance ou le partage d’écran.
Vérifiez les dépendances avant de désactiver un service. Avant de modifier le pare-feu ou les réglages d’accès à distance, notez la configuration actuelle et assurez-vous que l’équipe conserve un moyen d’administration fonctionnel.
La passation ne se résume pas au changement du mot de passe de la machine.Les jetons des dépôts, les informations d’enregistrement des runners, les identifiants des registres d’artefacts et les mots de passe d’export des certificats ont chacun leurs propres permissions. Au départ d’un membre, vérifiez-les un par un : changer uniquement le mot de passe VNC ne suffit pas.
Le fait qu’un certificat puisse être copié ne signifie pas que chaque tâche de build doit pouvoir y accéder. Traitez les certificats de signature comme des éléments distincts : précisez qui les importe, dans quel trousseau ils sont utilisés et quand les révoquer ou les renouveler.
Conservez les certificats, les clés privées correspondantes et les profils de provisionnement par projet. Avant l’importation, vérifiez leur usage, leur date d’expiration et les targets concernés. Ne validez jamais dans un dépôt de code un export contenant une clé privée.
Si vous devez créer une sauvegarde, utilisez un export protégé par mot de passe et transmettez ce mot de passe par un autre canal. Stockez la copie dans un espace géré par l’équipe au lieu de la laisser uniquement sur la machine de build.
À consigner : projet, usage, responsable, date d’expiration.
Nous conseillons de placer les identités de signature CI dans un trousseau dédié, distinct de celui utilisé au quotidien. Configurez le déverrouillage et les accès selon les besoins réels des builds ; n’autorisez pas tous les processus à accéder aux clés privées par simple commodité.
Si une tâche automatisée doit déverrouiller le trousseau, récupérez le mot de passe depuis une variable protégée de la CI. Validez d’abord la signature avec un build contrôlé, puis élargissez le périmètre des tâches du runner.
À consigner : trousseau, tâche concernée, méthode de déverrouillage.
Évitez d’afficher les mots de passe, jetons et mots de passe d’export des certificats dans les scripts. Pour diagnostiquer un problème, désactivez l’affichage détaillé des commandes sensibles et vérifiez les journaux avant de les téléverser.
Définissez séparément l’emplacement et la durée de conservation des archives, des paquets exportés et des symboles de débogage. Un build terminé ne garantit pas que ses artefacts sont sauvegardés : vérifiez au moins une fois que l’équipe peut récupérer les fichiers nécessaires depuis son espace de stockage.
À consigner : emplacement des artefacts, membres autorisés, durée de conservation.
Exécutez cette vérification en lecture seule sous le compte utilisateur prévu pour le build afin de confirmer que le trousseau contient l’identité de signature attendue. La sortie sert à une vérification locale : ne publiez pas l’ensemble des informations de l’environnement dans un espace public.
security find-identity -v -p codesigningCette commande affiche les identités disponibles ; elle n’importe aucun certificat et ne configure pas les autorisations d’accès au trousseau.
Tous les nœuds fonctionnent 365 jours par an. Le centre de données gère l’alimentation, le réseau et le refroidissement : vos pipelines nocturnes ne dépendent plus du Mac laissé au bureau.
| Domaine de gestion | Responsabilités du centre de données et de la plateforme | À la charge de l’équipe |
|---|---|---|
| Fonctionnement physique | Héberge la machine entière et gère l’alimentation, le réseau et le refroidissement. | Faites correspondre l’instance au projet concerné et désignez un responsable de l’équipement. |
| Accès au système | Fournit les identifiants d’accès à la machine via le portail. | Configurez les clés SSH, le mot de passe VNC et les autorisations des membres. |
| Environnement de build | Fournit un Mac physique dédié accessible à distance. | Gérez la chaîne d’outils Xcode, les runners, les dépendances et la concurrence des tâches. |
| Éléments du projet | Efface la machine entière à la fin de la location avant de la remettre à disposition. | Sauvegardez le code et les certificats, exportez les artefacts et révoquez les accès externes. |
La disponibilité des nœuds 365 jours par an ne garantit pas la réussite de chaque build. Les erreurs de script, certificats expirés, disques pleins ou modifications de configuration système par l’équipe doivent toujours être surveillés et traités dans le cadre du projet.
À la fin de la location, la machine est effacée avant d’être mise à la disposition du client suivant. Cet effacement supprime les données de la machine, mais ne révoque pas les accès à vos dépôts, à votre CI ou à d’autres systèmes : ces deux opérations sont distinctes.
Récupérez le code non encore poussé, les scripts de build, les archives, les paquets exportés, les symboles de débogage et les certificats nécessaires. Vérifiez l’intégrité des fichiers et assurez-vous que l’équipe peut les lire depuis un autre emplacement : la fin de la copie ne suffit pas.
Supprimez le runner concerné de la plateforme CI et révoquez les clés de déploiement et jetons d’accès qui ne sont plus utilisés. Renouvelez les secrets partagés conformément aux règles de l’équipe. L’effacement des fichiers locaux n’empêche pas les systèmes externes de faire encore confiance aux anciens identifiants.
Vérifiez la durée de location et les informations de l’instance dans le portail. Pour organiser l’ordre des exports ou clarifier le traitement des données, ouvrez un ticket à l’avance. Ne comptez pas sur la machine après l’échéance comme emplacement de sauvegarde et n’attendez pas la fin de la location pour chercher votre unique copie.
Tous les paiements sont facturés en dollars américains (USD). Seuls USDT-TRC20 et Visa / Mastercard / Amex (via Stripe) sont acceptés. Les moyens disponibles sont ceux indiqués par l’interface de paiement au moment du règlement.
Les paiements par carte sont traités par Stripe ; notre site ne conserve pas les numéros de carte. Pour toute question sur un paiement, indiquez le numéro de commande et son statut. N’envoyez jamais le numéro complet de votre carte, son cryptogramme ni une photo de la carte par ticket ou par e-mail.
Communiquez le numéro de commande à l’assistance, jamais les données confidentielles de votre carte.
Avant le paiement, vérifiez le réseau, l’adresse de réception et le montant affichés. Le rapprochement s’appuie sur les données de la blockchain. En cas de vérification, fournissez le numéro de commande et le hash de transaction, jamais la clé privée de votre portefeuille ni sa phrase de récupération.
Conservez le hash de transaction et vérifiez le statut du paiement avec le numéro de commande.
Pour signaler un problème de sécurité, vérifier un paiement ou poser une question sur le traitement des données, écrivez à support@pushmac.comou connectez-vous au portail pour ouvrir un ticket. Dans votre premier message, indiquez le numéro de l’instance, le nœud utilisé, les actions concernées et l’heure à laquelle le problème s’est produit, avec le fuseau horaire. Supprimez d’abord les secrets des journaux.
Une machine entière dédiée, disponible 365 jours par an. Désignez un responsable des accès, puis intégrez vos builds Xcode au pipeline de l’équipe.