Comment conserver durablement les artefacts de compilation Xcode Cloud ? Guide d’archivage 2026

Symptôme : vous devez retrouver une Archive, un journal ou un résultat de test après la fenêtre d’accès à Xcode Cloud.
Solution la plus rapide : sélectionnez les artefacts utiles, téléchargez-les pendant qu’ils sont accessibles, puis archivez-les avec leurs identifiants de construction et de commit. Ne considérez l’opération comme terminée qu’après avoir vérifié qu’un autre membre peut ouvrir les fichiers.

Ce guide s’adresse aux personnes qui publient seules et doivent conserver une Archive, des symboles ou des journaux pour diagnostiquer une version. Il convient aussi aux développeurs qui doivent revoir des résultats de test, ainsi qu’aux petites équipes qui veulent retrouver un artefact à partir d’une construction ou d’un commit.

Archives de publication : conserver les éléments utiles au diagnostic

Une Archive peut servir à retrouver le produit de compilation associé à une publication. Les informations de débogage, notamment les symboles nécessaires à la symbolication, répondent à un besoin différent : elles permettent d’interpréter certaines traces de plantage. Un journal de compilation décrit pour sa part le déroulement et les erreurs observées pendant la construction. Ces fichiers sont complémentaires, mais ne se remplacent pas.

Pour une version distribuée, partez du dossier de publication et remontez vers la construction correspondante. Relevez le nom de l’app, le flux de travail, l’identifiant de la construction, la version, le commit et la date de compilation. Ces éléments vous aideront à éviter une erreur fréquente : conserver une Archive exploitable, mais ne plus savoir quelle version du code ou quel envoi elle représente.

Apple indique que les artefacts de Xcode Cloud ne restent accessibles que pendant une période limitée après la fin d’une construction, jusqu’à 30 jours selon sa documentation. La durée réelle à prendre en compte est donc la fenêtre d’accès documentée par Apple, et non une promesse de stockage à long terme. Les versions destinées à être publiées doivent être archivées par l’équipe si elle veut les conserver au-delà de cette période. Consultez la documentation Apple sur la configuration d’un flux de travail Xcode Cloud avant de définir votre règle interne.

La question « combien de temps les artefacts Xcode Cloud restent-ils accessibles ? » a ainsi une réponse opérationnelle : prévoyez leur copie externe avant la fin de la fenêtre indiquée par Apple. Un artefact visible dans App Store Connect n’est pas encore une archive que votre équipe maîtrise. La disponibilité dans la plateforme et la conservation vérifiée dans votre propre espace sont deux états différents.

Pour décider si vous devez conserver l’Archive et les symboles ensemble, demandez-vous quel incident vous pourriez devoir analyser. Pour une simple vérification visuelle de la version, vous n’aurez peut-être pas besoin de tous les fichiers de diagnostic. Pour examiner ultérieurement des plantages associés à une version précise, les symboles et le lien vers la construction concernée deviennent importants. Apple explique les données de débogage à inclure dans une compilation dans sa documentation sur les informations de débogage.

Évitez de transformer chaque construction réussie en dossier de publication. Distinguez plutôt les builds quotidiens des versions candidate et des versions effectivement distribuées. Vous limitez ainsi le volume d’archives redondantes sans sacrifier les éléments nécessaires à une enquête ou à une reprise.

Résultats de test : conserver une preuve qui reste compréhensible

Un résultat de test n’est utile dans la durée que si vous pouvez le rattacher à ce qui a été exécuté. Un fichier isolé, même intact, ne répond pas aux questions essentielles : quelle construction l’a produit, quel flux de travail l’a lancé, quel commit était testé et quelles captures d’écran correspondent à l’échec ?

Pour les tests automatisés, sélectionnez les éléments qui permettent à quelqu’un de comprendre ou de reproduire l’incident : le paquet de résultats disponible, les journaux pertinents, les captures d’écran et les références de construction. Ne supposez pas que chaque exécution fournit les mêmes artefacts : vérifiez ce que le flux de travail a effectivement produit et ce que l’interface ou l’API expose pour cette construction. La documentation Apple sur les paquets de résultats et les retours concernant Xcode Cloud apporte un point de référence pour les résultats de test.

Lorsque vous téléchargez les fichiers, créez immédiatement un manifeste à côté d’eux. Il peut contenir le nom de l’app, le flux de travail, l’identifiant de construction, le commit, la version de Xcode si elle est connue, le type de fichier, la date de récupération et la personne responsable de l’archive. Si une capture montre un écran défaillant, indiquez dans le manifeste à quel résultat ou scénario elle se rapporte.

Un dossier nommé « tests » ne constitue pas une preuve de restauration. Si vous ne pouvez pas relier un résultat à une construction et à un commit, traitez-le comme un fichier non vérifié jusqu’à ce que cette relation soit rétablie.

La sélection dépend de l’usage. Pour reproduire une régression, gardez les informations qui permettent de retrouver le scénario et les traces associées. Pour une revue de qualité, le paquet de résultats et les captures qui attestent du comportement peuvent être plus utiles que les journaux complets. Pour une simple surveillance quotidienne, vous pouvez ne conserver que les échecs et les constructions signalées, selon la politique de votre équipe.

Récupération par l’API : automatiser le téléchargement sans confondre accès et archive

L’API App Store Connect peut être intégrée à un processus de récupération des artefacts de Xcode Cloud. La démarche générale consiste à repérer les constructions associées au flux de travail, à consulter leurs informations, puis à récupérer les artefacts disponibles et leurs informations de téléchargement. Apple documente les ressources de flux de travail et de constructions Xcode Cloud ainsi que les constructions exécutées.

Pour comprendre comment télécharger les artefacts via l’App Store Connect API, séparez les opérations au lieu de coder une récupération opaque. Interrogez d’abord les constructions visées. Ensuite, obtenez les artefacts associés et leurs attributs, puis suivez l’information de téléchargement fournie par l’API. La documentation Apple décrit les informations relatives aux artefacts, la lecture d’un artefact individuel et les attributs des artefacts. Vérifiez les noms de champs et les relations directement dans ces références avant de figer votre implémentation.

Ne considérez pas l’adresse de téléchargement comme un emplacement permanent. Utilisez-la pour récupérer le fichier, puis enregistrez celui-ci dans votre propre système de conservation. Les adresses et les champs exposés peuvent dépendre du fonctionnement actuel de l’API : contrôlez la documentation Apple au moment de mettre en place ou de modifier l’automatisation, sans coder en dur une durée d’expiration qui ne serait pas confirmée pour votre cas.

L’automatisation doit aussi traiter les échecs comme des états explicites. Conservez l’identifiant de la construction et l’étape atteinte, distinguez une erreur d’authentification d’un artefact momentanément indisponible, et prévoyez une nouvelle tentative contrôlée lorsque le téléchargement échoue. Après réception, vérifiez que le fichier existe et qu’il peut être ouvert ou extrait avant de marquer la récupération comme réussie. Une réponse positive de l’API ne prouve pas à elle seule que votre copie locale est complète.

Les clés d’accès et les jetons ne doivent pas être inscrits dans le dépôt avec le code de téléchargement. Limitez leur accès aux personnes et processus qui en ont besoin, et consignez leur gestion dans les règles de votre équipe. Apple décrit la génération des jetons destinés aux requêtes API. Référez-vous à cette documentation pour la méthode d’authentification en vigueur plutôt que de reprendre une configuration trouvée dans un ancien script.

Reprise d’une publication : organiser les archives pour l’équipe suivante

Un dossier de publication doit permettre à une personne qui n’a pas lancé la compilation de retrouver les éléments sans reconstituer l’historique à partir de messages épars. Organisez les fichiers par app, puis par version ou par construction, et associez chaque dossier au flux de travail et au commit. Le nom de dossier seul ne remplace pas un manifeste : utilisez les deux, car le nom aide à parcourir les archives tandis que le manifeste précise les relations.

Une structure possible, à adapter à votre système, sépare les versions distribuées, les résultats de test et les journaux de diagnostic. Évitez d’enregistrer les fichiers au seul nom « Archive » ou « dernière version », qui devient ambigu dès que plusieurs branches ou versions sont en circulation. Si un artefact est remplacé, gardez une trace de l’ancienne référence ou indiquez clairement quelle copie fait foi.

Lors d’un transfert à un nouveau membre, ne vous contentez pas de lui communiquer le chemin du dossier. Demandez-lui de retrouver une construction à partir du commit ou de la version, d’ouvrir l’Archive ou le résultat pertinent, et de vérifier que le manifeste indique ce qui manque. Ce contrôle révèle rapidement les problèmes de droits d’accès, de nommage, de fichier incomplet ou de dépendance à un compte personnel.

Pour une Archive iOS, vérifiez que le fichier récupéré correspond à la bonne version et qu’il s’ouvre dans les outils adaptés à votre flux de publication. Pour les symboles, vérifiez que les fichiers conservés sont ceux associés à la version concernée. Une Archive et un fichier de symboles portant des noms proches ne sont pas nécessairement issus de la même construction : rattachez-les au même identifiant et au même commit avant de déclarer le dossier complet.

Conservation sélective : arbitrer entre diagnostic, reproduction et coût de gestion

La règle la plus simple à tenir dans le temps consiste à définir des profils de conservation à partir de l’usage, et non à rendre chaque fichier permanent. Une version publiée peut justifier un ensemble plus complet qu’une construction quotidienne. Un échec de test reproductible peut justifier la conservation du résultat et des journaux associés, même s’il ne donne lieu à aucune publication.

Cette sélection n’impose pas une durée universelle ni une capacité de stockage arbitraire. Définissez une règle interne en fonction de vos besoins de support, de publication et de reproduction, puis vérifiez régulièrement qu’elle reste réalisable. Si vous n’avez jamais restauré une archive, vous ne savez pas encore si votre règle garantit une récupération.

Utilisez la liste ci-dessous avant de fermer une construction importante :

• [ ] Confirmer l’app, le flux de travail, la version, le commit et l’identifiant de construction.
• [ ] Choisir les artefacts nécessaires au diagnostic, aux tests ou à la reprise de publication.
• [ ] Télécharger les fichiers avant la fin de leur période d’accès indiquée par Apple.
• [ ] Enregistrer un manifeste qui relie chaque fichier à sa construction et à son commit.
• [ ] Vérifier que les fichiers sont présents et qu’ils peuvent être ouverts ou extraits.
• [ ] Faire retrouver un artefact à une autre personne à partir du manifeste.
• [ ] Noter les fichiers manquants, les accès requis et la personne chargée de corriger l’archive.

La réussite dépend de la chaîne complète : sélection, téléchargement, classement, contrôle et restauration. Un script qui ne fait que rapatrier des fichiers ne couvre que la récupération. Un système manuel peut fonctionner pour un faible nombre de versions, mais il dépend davantage de la discipline des personnes et de la régularité du classement.

Comparaison des méthodes : choisir selon l’effort de reprise

Le tableau suivant compare des façons de conserver les artefacts, sans supposer qu’une seule méthode convienne à toutes les équipes. Les appréciations sont qualitatives : elles servent à orienter le choix et doivent être confrontées à vos contraintes d’accès, de sauvegarde et de responsabilité.

Une méthode automatisée ne dispense pas d’un contrôle de restauration, et une copie sur Mac ne devient pas une sauvegarde simplement parce qu’elle est accessible. Décidez qui vérifie les fichiers, comment l’équipe signale une récupération incomplète et où se trouvent les références permettant de retrouver la construction source.

Pour les API, les champs, les relations entre constructions et artefacts ainsi que les informations de téléchargement doivent être vérifiés dans les références Apple au moment de la mise en œuvre. En cas d’évolution de l’API, testez d’abord le parcours sur une construction représentative et comparez le résultat téléchargé avec celui obtenu depuis l’interface, lorsque cette comparaison est disponible. Cette vérification évite de confondre un changement de réponse API avec une archive correctement constituée.

Si vous choisissez une machine Mac pour organiser les fichiers, évaluez séparément le système de stockage, les sauvegardes, les comptes autorisés et la procédure de récupération. Un environnement de travail peut aider à télécharger ou à ouvrir un artefact, mais ne garantit pas à lui seul sa conservation, son transfert ni sa restauration. La méthode doit être validée sur vos fichiers réels, notamment pour vérifier que les Archives et résultats de test s’ouvrent dans le contexte attendu.

Au terme de l’évaluation, donnez une appréciation interne à chaque méthode : adéquation forte si une autre personne retrouve et ouvre les artefacts sans intervention de l’auteur ; adéquation moyenne si la récupération dépend encore d’étapes manuelles documentées ; adéquation faible si l’équipe ne peut pas identifier la construction source ou confirmer l’intégrité des fichiers. Cette notation qualitative transforme une préférence d’outil en décision fondée sur une reprise effectivement testée.

Choisir un environnement Mac sans confondre poste de travail et sauvegarde

Une machine Mac distante peut faire partie du parcours lorsque vous devez récupérer des artefacts, les examiner avec des outils macOS ou préparer un transfert vers le stockage retenu par l’équipe. Elle n’est cependant ni l’archive officielle de Xcode Cloud ni une politique de sauvegarde. Avant de déplacer une étape sur un Mac, précisez qui télécharge, où la copie finale est conservée, comment elle est vérifiée et qui peut la restaurer.

Si vous envisagez cette option, confrontez votre besoin réel aux modalités proposées par MacDate, au lieu de déduire une capacité de stockage ou une méthode de transfert à partir du seul fait qu’il s’agit d’un Mac. Vous pouvez consulter le guide des tarifs des Mac mini M4 pour évaluer les modalités affichées, puis examiner un environnement Mac M4 en Virginie si sa localisation convient à votre organisation. Vérifiez directement les détails applicables à votre choix ; ne présumez pas qu’une machine conserve automatiquement les artefacts ni qu’elle remplace votre stockage d’équipe.

Si vous utilisez déjà un poste capable de récupérer et de vérifier les artefacts, ajouter une machine distante peut créer une étape et une responsabilité de plus sans résoudre le problème de conservation. À l’inverse, un processus actuel limité à des téléchargements ponctuels peut laisser des fichiers introuvables, dépendre d’un poste rarement disponible ou rendre la reprise difficile pour un autre membre. Dans ce cas, un Mac loué peut être une option plus souple qu’un achat dédié, à condition que le stockage durable, les sauvegardes et les accès soient définis séparément.

La décision ne se prend donc pas sur la seule présence d’un Mac. Commencez par réussir une récupération complète : retrouver une construction, télécharger les artefacts choisis, les ouvrir, vérifier leur lien avec le commit et faire répéter l’opération par une autre personne. Si cette vérification révèle que votre processus manque d’un environnement macOS accessible, examinez les modalités de location de MacDate et comparez-les à votre solution actuelle. Si vous avez déjà un environnement adapté et une restauration documentée, gardez votre flux existant : l’objectif est de récupérer les bons fichiers, pas d’ajouter une machine sans besoin démontré.