HexVM attribue à chaque commande un nœud physique Mac mini indépendant, et non une machine virtuelle. Votre équipe conserve ses dépôts, scripts et règles de publication existants, en déplaçant uniquement vers le cloud les étapes nécessitant macOS et Apple Silicon.
Dépôt de code
Déclenchement par commitNœud dédié
Vérification de l’environnementXcode
Build et testsArtefacts
Archivage et téléversementToutes les étapes ne doivent pas être migrées. Sélectionnez un scénario pour consulter le workflow recommandé, les éléments à préparer et les critères de validation avant mise en production, puis choisissez le nombre de nœuds et le mode d’exécution.
Après chaque commit, la plateforme du dépôt planifie un self-hosted runner qui exécute la restauration des dépendances, les tests, l’archivage et le téléversement des artefacts sur un nœud dédié. Votre équipe définit les règles de déclenchement, la stratégie de concurrence et les autorisations des secrets.
Voir le workflow CI/CD iOSConservez sur un nœud fixe les versions validées de Xcode, des outils en ligne de commande et les règles de cache des dépendances. Les tâches de chaque branche utilisent un répertoire de travail distinct ; les données temporaires sont supprimées après le build et seuls les artefacts nécessaires sont conservés.
Voir les méthodes d’automatisation macOSFigez la version du modèle, les dépendances d’exécution, les échantillons d’entrée et la référence de résultats afin de vérifier la compatibilité des outils, les scripts de traitement par lots et la reprise des tâches continues. Les limites de ressources dépendent du modèle disponible sélectionné.
Voir le périmètre des expérimentations IAVotre équipe contrôle les certificats, les profils de provisioning et l’accès au trousseau. Le nœud de build génère l’archive et effectue les vérifications ; la soumission finale est réalisée par un membre autorisé.
Voir le processus des certificats et de publicationVNC sert aux outils graphiques et aux contrôles d’interface ; SSH sert à synchroniser le code, exécuter les scripts et gérer les tâches continues. Lors de la première connexion, vérifiez les informations du nœud et remplacez immédiatement les identifiants temporaires.
Lire le guide d’accès à distanceUne machine physique dédiée convient aux pipelines nécessitant une version fixe de Xcode, un répertoire de cache stable et des limites d’autorisation claires. Le nœud ne partage pas ses ressources de calcul avec d’autres commandes, mais votre équipe reste responsable des droits du dépôt, des éléments de signature et du nettoyage des tâches.
Déclenchez la tâche avec une branche, un tag ou une pull request. Limitez d’abord côté dépôt les membres autorisés à déclencher le workflow de publication afin qu’une tâche de test standard n’accède pas aux droits de signature.
Validation : règles de déclenchement reproductiblesAttribuez des labels explicites au self-hosted runner, par exemple l’architecture, la version majeure de Xcode et l’usage. Évaluez la concurrence d’un nœud selon le pic de mémoire et le volume d’écriture disque de la tâche.
Validation : les tâches arrivent uniquement sur le nœud cibleFigez les versions des dépendances et exécutez les tests unitaires, tests d’interface ou contrôles statiques. En cas d’échec, conservez le code de sortie, le rapport de test et les journaux clés, plutôt que la seule dernière sortie affichée.
Validation : la cause de l’échec est identifiableDéverrouillez temporairement le trousseau requis par la publication, puis refermez immédiatement l’accès. Séparez les certificats et profils par projet et environnement ; ne les stockez pas durablement en clair dans un répertoire de build standard.
Validation : privilèges strictement minimauxTéléversez l’archive, les rapports de test et les fichiers de symboles, en enregistrant le hash du commit, le numéro de build et la version de l’outillage. Après réussite, supprimez les données sensibles du projet présentes dans les données dérivées.
Validation : artefacts traçablesLe Runner de test n’a pas besoin d’accéder aux certificats de publication ; seules les tâches d’archivage d’une branche protégée chargent les éléments de signature. Ainsi, même si le script d’une tâche standard rencontre une erreur, l’exposition des identifiants reste limitée.
Un nœud disponible en continu peut conserver l’outillage validé et le cache de téléchargement, mais chaque tâche doit utiliser un répertoire de travail distinct. Le cache accélère l’exécution, sans être une condition préalable à la réussite du build.
Créez un répertoire de travail par numéro de tâche et récupérez les fichiers temporaires à la fin du build. Ne laissez pas deux branches concurrentes modifier le même répertoire de dépendances ou chemin de sortie.
La clé de cache doit au moins inclure le résumé du fichier de verrouillage, la version majeure de l’outillage et l’architecture. En cas d’anomalie de cache, un build propre doit pouvoir être lancé en le contournant en un clic.
Conservez séparément les résultats de tests, les éléments préparatoires à la notarisation, les packages d’installation et les fichiers de symboles. Le nom des artefacts doit inclure la version, le numéro de build et l’identifiant du commit.
xcodebuild -version
xcode-select -p
swift --version
git rev-parse --short HEAD
xcodebuild test -scheme "Project" -destination "platform=macOS"Placez la vérification des versions au début des journaux de chaque build. En cas de dérive de l’environnement, comparez d’abord le chemin de l’outillage, le commit du projet et le fichier de verrouillage des dépendances avant de décider s’il faut nettoyer le cache.
Le Mac dans le cloud convient à la reproduction d’environnements expérimentaux, au contrôle de compatibilité de l’outillage et aux traitements par lots récupérables. Les capacités matérielles sont limitées aux deux configurations disponibles ; n’extrapolez pas les résultats à des spécifications non listées.
Conservez la version du modèle, le résumé des échantillons, la graine aléatoire et les paramètres d’exécution. Comparez les sorties avec le même jeu d’entrées ; une seule exécution ne remplace pas une validation complète.
Figez les versions du runtime, des packages de dépendances et des outils de conversion du modèle. Avant toute mise à niveau, dupliquez l’environnement et exécutez des échantillons de régression afin de confirmer les changements de sortie et de consommation de ressources.
Écrivez l’avancement et les résultats par lots pour les tâches continues, puis reprenez au dernier lot confirmé après l’arrêt du processus. Ne considérez pas l’état mémoire non persisté comme l’unique source de progression.
Enregistrez le pic mémoire, la croissance du disque, la durée des tâches et les échantillons en échec. À l’approche des limites du modèle, ajustez en priorité la taille des lots ou le fonctionnement de la file.
Copiez d’abord, validez ensuite, puis basculez. Conservez une solution de repli locale jusqu’à ce que le nœud cloud réussisse consécutivement les validations de build, d’autorisations et d’artefacts.
Étape 1
Copiez en priorité les données du projet via le dépôt, le stockage d’artefacts et un transfert chiffré. Excluez les caches, répertoires de build temporaires, anciens journaux et identifiants inutilisés.
Étape 2
Notez la version locale de Xcode, le chemin des outils en ligne de commande, les fichiers de verrouillage du gestionnaire de packages, la source des variables d’environnement et le point d’entrée du script de build, puis reproduisez-les dans le cloud.
Étape 3
Commencez par une branche hors publication, vérifiez les labels de planification, les délais d’expiration, les journaux et les règles de nettoyage, puis ouvrez les branches protégées et les tâches d’archivage signé.
Réalisez au moins un build propre, une reprise après échec, une validation des autorisations et une traçabilité d’artefact avant de faire du nœud cloud votre environnement d’exécution principal.
HexVM fournit un nœud physique dédié et un accès à distance. Votre équipe gère les demandes de certificats, les profils de provisioning, les droits du trousseau, les autorisations de publication et la soumission finale.
Définir l’usage des certificats, protéger les mots de passe d’exportation et limiter les membres autorisés.
Importer les éléments requis dans une session contrôlée, sans laisser le trousseau ouvert durablement.
Nom du certificat, état de validité, membres autorisés.
Gérer les profils par identifiant d’app et environnement de publication, puis supprimer les versions obsolètes.
Vérifier la correspondance avant le build et arrêter l’archivage en cas d’échec.
Identifiant d’app, informations d’équipe, version du fichier.
Approuver les branches protégées et les tâches de publication, puis contrôler les paramètres de build.
Effectuer l’archivage, l’export et le contrôle d’intégrité, avec un code de sortie explicite.
Hash du commit, numéro de build, résumé de l’archive.
Vérifier les informations de version, les éléments de confidentialité, les captures d’écran et le périmètre de publication.
Préparer les artefacts validés et l’environnement des outils de téléversement.
Soumetteur, version de l’artefact, résultat de la soumission.
Déverrouillez-le uniquement pendant la signature et refermez-le immédiatement à la fin de la tâche. Utilisez des stratégies d’accès distinctes selon les projets et environnements afin qu’une tâche de test n’hérite pas des droits de publication.
Vérifiez l’identifiant d’app, l’identité de signature, la version, le numéro de build et le résultat de l’export. Si un champ ne correspond pas aux attentes, arrêtez le téléversement au lieu d’ignorer manuellement l’erreur.
Révoquez l’enregistrement du Runner, supprimez les certificats et profils, nettoyez les identifiants du dépôt, les répertoires de build et les champs sensibles des journaux, puis confirmez le transfert des artefacts nécessaires.
Les six points suivants doivent avoir un responsable et une trace de validation clairement définis. Tout élément reposant encore sur un accord verbal peut devenir un risque en cas d’échec de build, de changement d’équipe ou de libération du nœud.
Choisissez la région selon la localisation des développeurs, le chemin des données du dépôt et la direction des téléversements d’artefacts. Les régions actuellement disponibles sont Singapour, Japon (Tokyo), Corée du Sud (Séoul), Hong Kong, États-Unis Est et États-Unis Ouest, soit 6 régions.
Exécutez d’abord un build complet sur un projet réel, puis choisissez HexVM M4 ou HexVM M4 Pro selon le pic mémoire, la croissance du disque et le mode de concurrence.
Séparez les droits d’administration du nœud, de développement quotidien, d’exécution CI et de publication. Lorsqu’un membre quitte l’équipe ou change de rôle, révoquez immédiatement ses clés et autorisations de dépôt.
Utilisez des identifiants de déploiement ou une autorisation Runner à portée limitée, en n’ouvrant que les dépôts nécessaires aux tâches. Les scripts ne doivent jamais écrire de jetons, clés privées ou identifiants complets dans les journaux.
Enregistrez la file des tâches, le taux de réussite, les causes d’échec, l’espace disque et la durée d’exécution. Les tâches continues doivent conserver des points de reprise et pouvoir être relancées en toute sécurité après un échec de build.
Par nœud, mesurez la durée effective des builds, l’attente en file, les périodes d’inactivité et le gain du cache. Les tâches courtes peuvent être planifiées à la journée ou à la semaine ; les pipelines continus peuvent être comparés sur des cycles mensuels ou trimestriels.
Effectuez un build propre et incrémental, les tests, l’archivage et le téléversement d’artefacts avec un dépôt réel. Pour obtenir de l’aide au diagnostic, préparez l’ID du nœud, la région, l’heure de l’incident, les étapes de reproduction et des journaux expurgés.
Comparez les deux modèles disponibles et les durées de location, configurez la région et les options, puis passez commande. Tous les frais sont facturés en dollars américains (USD) ; la disponibilité réelle est indiquée en temps réel dans la console.