Déploiement géré de Xcode

Si vous êtes administrateur Mac, vous avez peut-être des relations tumultueuses avec les développeurs de votre organisation qui travaillent sur macOS pour créer des applications pour les plateformes Apple. Souvent passionnés et très informés sur macOS, ils sont aussi très exigeants en ce qui concerne l’outillage et la configuration de leurs Mac. Pour dire les choses autrement, ils insistent pour que vous les laissiez configurer leur machine exactement selon leurs besoins.

Les développeurs sur macOS ne peuvent pas travailler sans Xcode, mais déployer ce logiciel dans un environnement géré pose de nombreux défis aux administrateurs.

Remarque : Au moment où j’écris ces lignes, Xcode 14.3.1 est la version officielle en circulation et Xcode 15 est en version bêta. Quelques changements ont été introduits dans Xcode 14 concernant le déploiement géré, et d’autres seront intégrés à Xcode 15. Xcode 15 étant encore en version bêta, il se peut que son comportement puisse changer avant sa sortie en septembre.

Installation de Xcode

Le premier défi consiste à installer l’application Xcode sur les Mac. La principale difficulté réside dans la taille du logiciel. Xcode 14 pèse en effet environ 23 Go et Xcode 15, environ 11,7 Go. Nous verrons plus tard pourquoi Xcode 15 est beaucoup plus léger.

App Store Mac

Apple met Xcode à disposition dans l’App Store Mac. Les administrateurs Mac devraient donc pouvoir déployer Xcode par le biais d’achats en volume avec Apps et Livres. Dans Apple Business Manager ou Apple School Manager, vous pouvez « acheter » un certain nombre de licences Xcode gratuites, puis utiliser la fonctionnalité de déploiement des applications de votre système de gestion pour les déployer. Cette approche présente de nombreux inconvénients, tous exacerbés par la nature et la taille inhabituelles de Xcode.

Avec le protocole MDM actuel (macOS Ventura et antérieurs), le client n’envoie aucun feedback au serveur après l’émission de la commande d’installation d’une application. L’utilisateur local n’a donc aucun moyen de voir l’état de l’installation. L’utilisateur ne se rendra peut-être même pas compte que sa machine est en train de télécharger et d’installer un logiciel très volumineux en arrière-plan ! Si l’installation côté client échoue pour une raison ou une autre, ni l’utilisateur ni le serveur MDM n’en sont informés. Et le téléchargement et l’installation peuvent échouer pour de nombreuses raisons différentes.

L’utilisateur peut fermer son ordinateur portable, le mettre en veille ou quitter le réseau pendant le processus, qui échouera immanquablement. Cela peut se produire avec n’importe quel logiciel, mais la taille de Xcode augmente la probabilité d’échec, d’autant qu’il n’y a aucun moyen d’informer l’utilisateur de la situation.

L’installation via l’App Store a un avantage : vous pouvez utiliser la mise en cache des contenus d’un Mac sur votre réseau. Cela accélère considérablement le téléchargement.

Apple a prévu de modifier le protocole MDM dans iOS 17 et macOS Sonoma, et ces changements devraient améliorer considérablement le workflow du déploiement géré des applications du Mac App Store. Il faudra toutefois un certain temps pour que les développeurs MDM implémentent ces nouvelles fonctionnalités et pour que les organisations, les utilisateurs et les développeurs adoptent les nouvelles versions de Xcode et des systèmes d’exploitation. Il faudra donc sans doute patienter avant que nous puissions tous profiter de ces nouvelles fonctionnalités.

Installation à l’aide de règles

En général, les installations depuis l’App Store Mac fonctionnent mieux lorsqu’elles sont initiées par l’utilisateur via le Self Service. En effet, l’utilisateur sait qu’une installation est prévue et qu’elle peut prendre un certain temps. Mais jusqu’à Ventura du moins, les installations par le biais de règles sont plus fiables qu’avec l’achat en volume dans Apps et Livres.

Il faut aussi savoir que le déploiement via Apps et Livres délivre systématiquement la dernière version de l’application, hors bêta. Une fois installé, Xcode va également télécharger et appliquer automatiquement les mises à jour, s’il n’est pas en cours d’exécution. Vous ne pouvez pas non plus gérer le déploiement de versions antérieures ou bêta. Selon le fonctionnement de votre organisation, cette particularité peut être un avantage ou un inconvénient majeur.

Réempaqueter Xcode

Si vous souhaitez installer Xcode avec une règle Jamf, vous devez fournir un paquet d’installation – ou pkg – incluant Xcode.

Apple fournit des téléchargements pour Xcode sur son portail destiné aux développeurs. La page de téléchargements répertorie (entre autres choses) les versions précédentes et bêta de Xcode. Vous devez disposer d’un compte Développeur Apple pour accéder à cette page, mais le niveau gratuit suffit. Personnellement, j’utilise également la page Xcode Releases qui présente une vue d’ensemble très pratique.

Xcode se télécharge sous la forme d’une archive xip. Il suffit de double-cliquer sur l’archive dans Finder pour l’extraire. L’extraction prendra beaucoup de temps, d’une part parce que l’archive contient plus de 100 000 fichiers, et d’autre part parce que Mac contrôle la signature et l’intégrité de l’archive.

Une fois que vous avez extrait Xcode, vous pouvez le réempaqueter. Vous n’avez pas besoin d’un outil d’empaquetage sophistiqué, productbuild suffit amplement :

% productbuild --component /chemin/vers/Xcode.app /Applications Xcode-14.3.1.pkg

Le premier chemin après l’indicateur --component pointe vers l’emplacement du bundle de l’application Xcode ; le second est le chemin de l’emplacement où il sera installé sur le système cible. Le dernier argument est le nom du fichier pkg qui sera créé. Je recommande fortement d’ajouter le numéro de version dans les noms de fichiers pkg. Il n’est pas nécessaire que Xcode soit installé dans /Applications, et il n’a pas besoin d’être lancé ou configuré pour cette commande de réempaquetage.

Le processus prendra beaucoup de temps.

Remarque 1 : Si la durée du téléchargement et la taille du fichier vous préoccupent, vous pouvez la réduire d’environ 25 % en ajoutant l’option « --componentcompression auto ». La compression (puis la décompression) prendra plus de temps avec cette option, mais le fichier sera moins volumineux. Vous trouverez plus d’informations à ce sujet dans cet article.

Remarque 2 : Si vous avez besoin de pouvoir installer plusieurs versions de Xcode sur le même système (la version bêta et la version actuelle, par exemple), vous devez désactiver le marqueur « relocatable » dans le paquet d’installation. Vous trouverez des instructions à ce sujet dans cet article, mais le plus simple est d’utiliser mon outil quickpkg.

Configuration au premier lancement pour les utilisateurs non-administrateurs

Le travail de l’administrateur Mac n’est pas terminé une fois que Xcode est déployé. Il faut également configurer Xcode pour qu’il soit utilisable par les utilisateurs. Lorsque vous lancez une nouvelle version de Xcode pour la première fois sur un nouveau système, elle vous demande d’installer des composants supplémentaires qui nécessitent des privilèges d’administrateur.

Si les utilisateurs de votre déploiement ont les autorisations en question, cela ne devrait pas poser de problèmes. Ils peuvent autoriser eux-mêmes ces processus. Mais certains déploiements comprennent des utilisateurs standards qui ne peuvent pas autoriser ces étapes.

Soulignons au passage que les utilisateurs standards sont un peu dépassés et que l’usage de ce profil n’est plus recommandé dans la plupart des déploiements. En effet, avec l’architecture et la sécurité intégrée de macOS, ses avantages sont minimes (consultez à ce sujet le billet de Graham Gilbert et sa présentation MacSysAdmin).

Cela dit, certains déploiements, dans les établissements d’enseignement en particulier, n’ont pas cette possibilité. Et si certains administrateurs Mac ont d’autres préférences, ils devront choisir avec soin leurs arguments qu’ils présenteront à l’équipe de gestion et de sécurité de leur organisation. Quelle qu’en soit la raison, beaucoup d’entre nous doivent gérer des utilisateurs standards.

Une chose reste vraie dans tous les cas de figure : en automatisant une partie de la configuration en arrière-plan, vous offrirez une expérience plus agréable dans l’ensemble, même si les utilisateurs ont des privilèges d’administrateur.

Lors du premier lancement de Xcode, les étapes suivantes nécessitent des privilèges administrateurs :

• Sélectionner la nouvelle version si plusieurs versions de Xcode sont installées
• Accepter l’accord de licence de Xcode et des SDK d’Apple
• Installer des composants supplémentaires
• Activer la sécurité des outils de développeurs pour les utilisateurs non-administrateurs

Des outils de ligne de commande permettent de réaliser toutes ces étapes : nous pouvons donc les automatiser à l’aide d’un script. Ces commandes devront être exécutées en tant que root, par exemple à partir d’une règle de script post-installation de Jamf Pro.

Tout d’abord, nous vérifions que les outils de ligne de commande utilisent le dernier Xcode – que nous venons d’installer – avec la commande xcode-select. Ensuite, nous utilisons xcodebuild pour accepter la licence et lancer le workflow « premier lancement ». Ces deux étapes nécessitent des privilèges d’administrateur.

À l’étape suivante, nous imbriquons le groupe « everyone » dans le groupe « _developer ». Cette opération prépare la prochaine commande qui activera DevToolSecurity. On autorise ainsi les administrateurs ou les membres du groupe _developer à exécuter certains débogueurs et outils d’analyse des performances sans avoir besoin de saisir leur mot de passe.

En imbriquant le groupe everyone dans le groupe _developer, nous faisons en sorte que tous les utilisateurs du système, même s’ils sont créés après l’exécution de ce script, au groupe qui accorde les privilèges. Si vous préférez imposer certaines limites, vous pouvez modifier dseditgroup pour ajouter uniquement l’utilisateur actuellement connecté.

Les processus activés par DevToolsSecurity sont surtout utiles pour les workflows de débogage et de performance qui emploient des outils en ligne de commande et des scripts. Si vous êtes particulièrement sensible à la sécurité, faites un test pour déterminer si vos développeurs peuvent utiliser leurs workflows sans activer cette fonction.

Gestion des SDK de plateforme avec Xcode 14 et 15

Il vous reste une chose à préinstaller. Au cours des dernières années, Apple a considérablement réduit la taille des téléchargements de Xcode :

• Xcode 11 : 7,5 Go
• Xcode 12 : 11 Go
• Xcode 13 : 10 Go
• Xcode 14 : 7 Go*
• Xcode Go15 Go: 3,1 Go**

* n’inclut pas les SDK de watchOS et tvOS
** n’inclut pas les SDK d’iOS, watchOS, tvOS et visionOS.

Ces économies sont principalement dues au fait que le téléchargement de Xcode n’inclut plus tous les SDK de plateforme : Xcode 14 est livré avec macOS et iOS ; Xcode 15 ne comprend que macOS. Comme les SDK de plateforme sont indispensables pour développer et émuler des applications sur les différentes plateformes, les utilisateurs sont invités, au premier lancement, à indiquer quels SDK de plateforme ils souhaitent télécharger et installer.

Autrement dit, les téléchargements volumineux n’ont pas été supprimés – ils sont simplement différés. Au total, Xcode 15 et tous les SDK de plateforme (iOS, watchOS et tvOS) totalisent plus de 17 Go, auxquels visionOS ajoute près de 7 Go supplémentaires. Les nouvelles versions de Xcode ne permettent donc pas de réaliser de réelles économies en termes de téléchargement, bien au contraire. En revanche, la réduction considérable de la taille du paquet d’installation initiale devrait fiabiliser les téléchargements à partir du Mac App Store ou à l’aide d’Apps et de Livres.

Pour le déploiement géré, les choses sont plus simples : l’utilisateur de Xcode n’a pas besoin d’avoir des privilèges d’administrateur pour télécharger et installer des SDK supplémentaires. Il choisit les SDK de son choix au premier lancement, ou se rend dans l’onglet « Plateformes » des réglages de Xcode pour les ajouter par la suite.

Mais vous pouvez encore faciliter la vie des utilisateurs finaux. Si vous déployez Xcode dans un environnement de salle de classe, il n’est pas question de faire perdre du temps à tout le monde avec un gros téléchargement. Il se peut aussi que vous vouliez déployer Xcode sur un Mac pour des processus de compilation automatisés, sans qu’aucun utilisateur ne soit impliqué. Dans ce cas, il peut être intéressant d’automatiser le déploiement des SDK de plateforme nécessaires.

De manière assez surprenante, la documentation d’Apple à ce sujet nous oriente à nouveau vers la commande xcodebuild.

La commande xcodebuild propose trois options utiles : -downloadAllPlatforms télécharge toutes les plateformes disponibles. C’est pratique, mais on parle de plus de 20 Go pour Xcode 15. L’option -downloadAllPreviouslySelectedPlatforms est particulièrement utile après une mise à jour de Xcode.

Enfin, -downloadPlatform télécharge la plateforme désignée. Les noms des différentes plateformes sont absents de la documentation et de l’aide à la commande, mais ils sont relativement faciles à deviner : iOS, watchOS, tvOS et xrOS (qui désigne le SDK visionOS ; cette dénomination peut évoluer au cours de la phase bêta).

Si vous relancez la commande alors qu’une plateforme est déjà installée, l’outil le détecte et ne renouvelle pas le téléchargement. On peut donc ajouter sans inquiétude les plateformes souhaitées à la fin de notre script de configuration :

Xcode 14 est livré avec le SDK iOS, mais xcodebuild détecte qu’il est déjà présent et ne le télécharge pas à nouveau. Lors de mes tests, le téléchargement utilisait un serveur de cache local, ce qui a considérablement accéléré les choses.

Avec Xcode 15, la vérification du téléchargement s’accompagnait d’une barre de progression à l’intention de l’utilisateur. Cela peut être très déconcertant si cela se produit alors qu’il n’a pas lancé le processus, mais cela ne devrait pas poser de problème dans le cadre d’un workflow de déploiements initial.

Conclusion

Vous trouverez sur GitHub un script rassemblant toutes ces étapes, prêt à intégrer dans une règle.

Xcode est une application essentielle pour beaucoup de nos utilisateurs. Dans les déploiements gérés, sa distribution présente certaines difficultés. Les outils et les scripts présentés ici vous aideront à créer une excellente expérience pour vous comme vos utilisateurs.

L’approche présentée ici a bien fonctionné pour moi, mais ce n’est sans doute pas la seule, ni même la meilleure, dans certains environnements.