Mac distant pour Xcode : compilation locale, compilation distante ou partage d'écran ?

Partager un projet sur le réseau ne déplace pas Xcode, car l'application continue de tourner sur votre Mac et continue de demander les données du projet au serveur. Exécuter Xcode sur le Mac distant et regarder son écran est une autre disposition, où l'application et ses fichiers restent ensemble et où le lien ne transporte que l'affichage et votre saisie. Décider laquelle vous voulez, avant de configurer quoi que ce soit, règle l'essentiel de la confusion ultérieure.

Trois dispositions couvrent les cas habituels, et elles diffèrent par l'endroit où vit l'espace de travail et par la machine qui compile. Notez votre réponse pour ces deux points avant de continuer.

Nommez la machine qui exécute Xcode

Dans la première disposition, tout est local : la copie de travail, l'index et la compilation vivent sur votre Mac, et le réseau ne transporte que le trafic du dépôt et des dépendances. Dans la deuxième, le projet reste sur le Mac distant avec Xcode, si bien que l'indexation et la compilation se font à côté des fichiers pendant que le lien transporte le contenu de l'écran et les frappes. Dans la troisième, l'édition se fait localement et une compilation s'exécute sur un hôte distant après une remise explicite de la source. Le tableau nomme ce que chacune déplace.

Lisez d'abord la colonne du milieu, car elle décide où les défaillances apparaîtront. Un flux de travail dont la source est distante échoue quand le lien est lent, tandis qu'un flux avec un compilateur distant échoue quand la remise est ambiguë. Seule la troisième vous rend responsable des deux.

Comptez les allers-retours, pas les mégaoctets

Un éditeur et un indexeur émettent beaucoup de petites opérations de fichiers, et chacune devient un aller-retour lorsque le système de fichiers est distant. Cela rend un espace de travail monté sensible à la latence d'une manière qu'une seule grosse copie ne l'est pas, ce qui explique pourquoi chronométrer un transfert de fichier ne vous dit presque rien sur la sensation du flux de travail. L'affichage distant a le profil inverse : il déplace un flux continu et tolère mieux le débit que le retard. Comparer les deux avec un seul chiffre produit une réponse fausse et assurée.

Aucune des dispositions n'est la plus rapide par nature. Le bon choix dépend du travail que vous faites réellement, et c'est pourquoi l'étape suivante consiste à essayer ce travail plutôt qu'un repère.

Rendez la remise de la source explicite

Quand les deux machines détiennent une copie de travail, décidez laquelle fait autorité et quelle révision la compilation distante a utilisée. Un commit est une remise plus claire que deux outils modifiant un seul arbre de travail monté, car le commit a une identité et le montage n'en a pas. La sortie générée et les données d'index ont aussi besoin d'un propriétaire, car elles sont reconstruites à partir de la source et ne devraient pas voyager comme si elles étaient la source. Un miroir bidirectionnel sans règles de conflit n'est pas un flux de travail, c'est une course.

Compiler à distance exige aussi que l'hôte distant dispose de la bonne chaîne d'outils et les identifiants pour les dépendances privées. Un VPN qui vous permet d'atteindre l'hôte ne lui prête pas l'accès à votre compte, et il n'y installe pas Xcode.

Vérifiez le chemin avant de vous engager dans un flux de travail

Vérifiez l'hôte distant avant de concevoir autour de lui, puis mesurez le lien avec les opérations que le flux de travail effectuera réellement. Les commandes ci-dessous vérifient la chaîne d'outils, le répertoire de développeur actif et le coût d'observation des fichiers qui rend douloureux les espaces de travail distants. Exécutez la dernière sur le chemin réseau plutôt qu'en local.

xcode-select -p
xcodebuild -version
ssh mac-builder 'xcodebuild -version'
time git status --porcelain

Un hôte sans installation complète de Xcode renvoie une erreur de xcodebuild, et c'est un problème de chaîne d'outils et non de réseau. Le répertoire de développeur montre quel Xcode la compilation utilisera, et un chemin qui ne pointe que vers les outils en ligne de commande signifie que l'application n'est pas installée. Chronométrer la commande d'état du dépôt sur le partage monté expose directement le coût de l'aller-retour, et le comparer à une exécution locale donne le chiffre qui compte. Si cet écart est déjà désagréable, le flux avec l'espace monté sera pire sous un vrai éditeur.

Notez quelle disposition vous avez choisie, quelle machine possède la source et comment la remise fonctionne. Cette note transforme la prochaine intégration ou le remplacement d'un ordinateur portable en tâche de configuration plutôt qu'en enquête.