Mac remoto per Xcode: build locale, build remota o condivisione dello schermo?
Un'area di lavoro montata e un Xcode remoto spostano dati diversi. Decidi dove vivono il sorgente, l'indice e la build, poi misura i viaggi di andata e ritorno.
Condividere un progetto sulla rete non sposta Xcode, perché l'app continua a essere eseguita sul tuo Mac e continua a chiedere i dati del progetto al server. Eseguire Xcode sul Mac remoto e guardarne lo schermo è un'altra disposizione, in cui l'app e i suoi file restano insieme e il collegamento trasporta solo la visualizzazione e il tuo input. Decidere quale delle due vuoi, prima di configurare qualsiasi cosa, risolve la maggior parte della confusione successiva.
Tre disposizioni coprono i casi abituali, e differiscono per dove vive l'area di lavoro e per quale macchina compila. Annota la tua risposta su entrambi i punti prima di continuare.
Nomina la macchina che esegue Xcode
Nella prima disposizione tutto è locale: la copia di lavoro, l'indice e la build vivono sul tuo Mac, e la rete trasporta solo il traffico del repository e delle dipendenze. Nella seconda il progetto resta sul Mac remoto con Xcode, così l'indicizzazione e la compilazione avvengono accanto ai file mentre il collegamento trasporta il contenuto dello schermo e le battute. Nella terza la modifica avviene localmente e una build viene eseguita su un host remoto dopo una consegna esplicita del sorgente. La tabella nomina cosa sposta ciascuna.
| Arrangement | Where the source lives | What crosses the link |
|---|---|---|
| Everything local | Local disk | Repository and dependency traffic |
| Remote Xcode, screen shared | Remote disk | Display frames and input events |
| Local edit, remote build | Both, with a handoff | Source transfer, then build output |
Leggi prima la colonna centrale, perché decide dove appariranno i guasti. Un flusso di lavoro la cui fonte è remota fallisce quando il collegamento è lento, mentre un flusso con un compilatore remoto fallisce quando la consegna è ambigua. Solo la terza ti rende responsabile di entrambe.
Conta i viaggi di andata e ritorno, non i megabyte
Un editor e un indicizzatore emettono molte piccole operazioni sui file, e ciascuna diventa un viaggio di andata e ritorno quando il file system è remoto. Questo rende un'area di lavoro montata sensibile alla latenza in un modo in cui una singola copia grande non lo è, ed è per questo che cronometrare un trasferimento di file non ti dice quasi nulla su come si sente il flusso di lavoro. La visualizzazione remota ha il profilo opposto: sposta un flusso continuo e tollera meglio la larghezza di banda del ritardo. Confrontare le due con un solo numero produce una risposta sbagliata e sicura di sé.
Nessuna delle due disposizioni è la più veloce per natura. La scelta giusta dipende dal lavoro che fai davvero, ed è per questo che il passo successivo è provare quel lavoro invece di un riferimento.
Rendi esplicita la consegna del sorgente
Quando entrambe le macchine hanno una copia di lavoro, decidi quale è autoritativa e quale revisione ha usato la build remota. Un commit è una consegna più chiara di due strumenti che modificano un solo albero di lavoro montato, perché il commit ha un'identità e il montaggio no. Anche l'output generato e i dati dell'indice hanno bisogno di un proprietario, perché vengono ricostruiti dal sorgente e non dovrebbero viaggiare come se fossero sorgente. Uno specchio bidirezionale senza regole di conflitto non è un flusso di lavoro, è una corsa.
Compilare in remoto richiede anche che l'host remoto disponga della catena di strumenti giusta e le credenziali per le dipendenze private. Una VPN che ti permette di raggiungere l'host non gli presta l'accesso al tuo account, e non vi installa Xcode.
Controlla il percorso prima di impegnarti in un flusso di lavoro
Verifica l'host remoto prima di progettarci intorno, poi misura il collegamento con le operazioni che il flusso di lavoro eseguirà davvero. I comandi qui sotto controllano la catena di strumenti, la directory dello sviluppatore attiva e il costo di osservazione dei file che rende dolorose le aree di lavoro remote. Esegui l'ultimo sul percorso di rete e non localmente.
xcode-select -p
xcodebuild -version
ssh mac-builder 'xcodebuild -version'
time git status --porcelain
Un host senza un'installazione completa di Xcode restituisce un errore da xcodebuild, e questo è un problema della catena di strumenti, non della rete. La directory dello sviluppatore mostra quale Xcode userà la build, e un percorso che punta solo agli strumenti da riga di comando significa che l'app non è installata. Cronometrare il comando di stato del repository sulla condivisione montata espone direttamente il costo del viaggio di andata e ritorno, e confrontarlo con un'esecuzione locale dà il numero che conta. Se quel divario è già spiacevole, il flusso con l'area montata sarà peggiore sotto un vero editor.
Annota quale disposizione hai scelto, quale macchina possiede il sorgente e come funziona la consegna. Quella nota trasforma il prossimo inserimento o la sostituzione del portatile in un compito di configurazione invece che in un'indagine.