L’annulation automatique des builds Xcode Cloud convient aux validations de branche que des commits plus récents rendent obsolètes ; désactivez-la pour une archive ou une livraison qui doit aller à son terme. Avant d’activer l’option, vérifiez que le workflow peut être relancé sans perdre un résultat nécessaire.

Cet article s’adresse aux responsables IT et plateforme qui définissent les déclencheurs de Xcode Cloud.
Il aide les responsables des tests UI à choisir entre une validation systématique et un workflow ciblé.
Les équipes qui gèrent des archives ou une distribution peuvent s’en servir pour contrôler les risques d’interruption.

Distinguer les validations remplaçables des livraisons

L’annulation automatique n’est pas un bouton général de nettoyage de file d’attente. La documentation Apple précise que, lorsque l’option est activée, l’arrivée d’un nouveau build dans le même workflow peut annuler un build en cours. Le périmètre important est donc le workflow lui-même : ne supposez pas qu’une nouvelle exécution dans un autre workflow remplacera l’ancienne. Consultez la référence officielle des workflows Xcode Cloud avant de choisir votre politique.

Pour décider, posez-vous une question opérationnelle : si une exécution s’arrête parce qu’un commit plus récent arrive, pouvez-vous encore obtenir le résultat attendu en laissant ce nouveau commit terminer ? Si oui, la validation peut être remplaçable. Si l’exécution produit une archive requise, alimente une distribution ou sert de preuve indépendante, elle ne l’est pas forcément.

Scénario Déclenchement à privilégier Annulation automatique Contrôle avant adoption
Validation courante d’une branche Changements sur les branches concernées À activer si le résultat précédent devient inutile Le commit le plus récent obtient bien le résultat de validation requis
Commits rapprochés Déclencheurs limités au périmètre utile À activer seulement pour les validations substituables du même workflow Les exécutions annulées restent identifiables pour le diagnostic
Tests UI de régression Workflow séparé ou déclencheur plus ciblé Selon le besoin de conserver chaque résultat La porte de validation ne dépend pas d’un test annulé
Archive ou distribution Workflow de publication dédié À désactiver si une interruption met en péril la livraison Build, archive et distribution sont tous vérifiés

Les conditions de démarrage configurables et les actions d’un workflow sont décrites dans la documentation des workflows Xcode Cloud et dans les instructions de configuration d’un premier workflow. Utilisez ces références pour vérifier les options visibles dans votre interface plutôt que de transposer une configuration conçue pour une autre branche ou une autre étape de livraison.

Régler les validations de branche et les pushes rapprochés

Une validation de branche répond généralement à une question limitée : le commit testé peut-il passer les contrôles requis ? Si un nouveau commit remplace le précédent pour cette décision, laisser le build obsolète continuer peut produire un résultat qui ne correspond plus à l’état que l’équipe veut intégrer. L’annulation automatique peut alors être pertinente, à condition que le nouveau build soit réellement déclenché et que son résultat soit suivi.

Les conditions de déclenchement méritent autant d’attention que l’annulation. La documentation d’Apple présente la stratégie de workflow comme un choix à adapter au processus de développement ; consultez son guide de conception d’une stratégie Xcode Cloud. Un workflow déclenché trop largement peut lancer des contrôles inutiles. Une condition trop étroite peut, à l’inverse, laisser une modification importante sans validation. Définissez le périmètre à partir des branches et des événements qui doivent réellement bloquer ou autoriser la suite du travail.

Pour un développeur qui pousse plusieurs fois avant la fin d’un build, ne confondez pas « conserver le plus récent » et « supprimer toutes les exécutions précédentes ». Le premier choix convient si les builds précédents ne portent aucune information indépendante. Le second peut effacer des éléments utiles pour comprendre une régression, un comportement intermittent ou une différence entre deux modifications. Dans ce cas, conservez un workflow de diagnostic ou un historique distinct au lieu de rendre la validation courante responsable de toute l’observabilité.

Procédez par vérification contrôlée :

  • Repérez le workflow concerné et notez les conditions qui le lancent.
  • Relevez le commit et l’origine de déclenchement dans l’historique.
  • Activez l’annulation automatique uniquement pour une validation que le résultat suivant peut remplacer.
  • Poussez une modification de test, puis une autre avant la fin de la première exécution.
  • Vérifiez quelle exécution a été annulée, laquelle a terminé et quel commit porte le résultat utilisé par l’équipe.

Les variables d’environnement fournies par Xcode Cloud peuvent aider à rendre cette vérification plus lisible dans les scripts : la référence Apple documente notamment CI_BUILD_NUMBER, CI_WORKFLOW et CI_PRIMARY_REPOSITORY_BRANCH. Reportez-vous à la référence des variables d’environnement Xcode Cloud pour confirmer leur signification avant de les utiliser dans vos journaux. Ces identifiants facilitent le rapprochement d’une exécution avec son workflow et sa branche ; ils ne prouvent pas, à eux seuls, qu’une validation a réussi.

Cibler les tests UI sans fragiliser la porte de validation

Les tests UI peuvent mobiliser une chaîne d’actions et des configurations distinctes des contrôles de compilation courants. Les lancer à chaque changement de branche n’est pas automatiquement la meilleure stratégie. Si leur résultat n’est pas nécessaire pour chaque commit intermédiaire, créez des conditions de déclenchement plus précises ou séparez le workflow de régression du workflow de validation rapide. La documentation Apple détaille les actions configurables dans un workflow Xcode Cloud ; examinez les actions réellement exécutées avant de décider à quel événement les associer.

Considérez un cas concret : une équipe modifie une interface, pousse plusieurs corrections rapprochées et attend une validation avant intégration. Si le test UI porte seulement sur l’état final, une exécution antérieure peut être annulable lorsque la suivante la remplace. En revanche, si chaque résultat sert à isoler une anomalie visuelle ou à expliquer une régression, l’annulation peut supprimer une preuve utile. L’usage créatif compte aussi : pour une application audio ou vidéo, une modification d’interface peut affecter des parcours de lecture ou de montage qui méritent un scénario de régression dédié, sans imposer que tous les contrôles soient déclenchés par chaque événement.

Attention : un build annulé n’est ni un test réussi ni une approbation de la modification. Si votre porte de validation exige un résultat UI, vérifiez qu’un résultat valide existe pour le commit concerné avant de poursuivre.

La documentation Apple sur l’exécution des tests et l’interprétation des résultats aide à distinguer l’état d’une exécution de l’interprétation de ses résultats. Dans votre procédure d’équipe, indiquez explicitement quel workflow fournit le statut qui autorise l’intégration. Si le workflow UI est indépendant, ne laissez pas une validation de branche réussie masquer l’absence du résultat de régression attendu.

Questions de décision fréquentes

Une exécution déjà en cours peut-elle être interrompue ?
Oui. La documentation Apple indique que l’activation de l’annulation automatique permet à un nouveau build du même workflow d’annuler un build en cours. Vérifiez le workflow et le commit avant de généraliser ce comportement. Un build annulé doit apparaître comme tel dans l’historique ; il ne constitue pas une validation réussie.

Comment traiter des pushes successifs ?
Limitez d’abord les déclencheurs au workflow qui répond à la validation courante. Ensuite, n’autorisez l’annulation que si un commit plus récent rend effectivement le résultat précédent inutile. Gardez un parcours distinct pour les diagnostics ou les éléments d’audit qui doivent survivre à ces remplacements.

Les tests UI doivent-ils suivre chaque changement de branche ?
Non, pas par principe. Vous pouvez les isoler derrière des conditions plus ciblées si leur exécution n’est pas nécessaire pour chaque modification intermédiaire. Définissez toutefois la porte de validation qui exige leur résultat et vérifiez qu’elle ne considère pas une exécution annulée comme une réussite.

Que protéger dans un workflow de publication ?
Vérifiez si le workflow produit un build, une archive ou une distribution dont votre processus dépend. La documentation décrit les workflows de création d’une version destinée à la distribution. Si une annulation peut interrompre une étape requise, désactivez l’option pour ce workflow ou séparez la validation quotidienne de la livraison.

Protéger les archives et les résultats de distribution

Une archive de publication n’a pas la même fonction qu’une validation de branche. Elle peut être attendue par une étape de distribution, par un responsable de mise en production ou par un processus interne de contrôle. Si une nouvelle exécution du même workflow peut annuler celle qui prépare cet artefact, le remplacement n’est pas forcément sans conséquence. N’activez pas l’option par simple cohérence avec le workflow de branche.

Les instructions d’Apple sur la création d’un build destiné à la distribution précisent les étapes propres à cette catégorie de workflow. Pour les uploads, consultez également les instructions relatives au téléversement de builds. Après une exécution, vérifiez l’état du build dans la référence des états de build et contrôlez séparément les étapes d’archive et de distribution requises par votre processus.

Dans la procédure de publication, consignez ce qui fait foi : l’identifiant du build, l’état affiché, le résultat d’archive attendu et la confirmation de distribution si elle fait partie du parcours. Le fait qu’un workflow ait démarré, ou qu’il soit terminé, ne suffit pas à prouver que l’application est disponible au destinataire prévu. Si l’équipe ne peut pas récupérer l’artefact après une interruption, séparez la publication des validations susceptibles d’être remplacées.

Définir le passage entre Xcode Cloud et un Mac distant

Tout ne doit pas nécessairement rester dans un workflow Xcode Cloud unique. Certaines tâches peuvent s’intégrer à vos workflows existants ; d’autres peuvent demander un environnement que votre équipe veut gérer plus directement, des scripts propres à son processus ou un point d’exécution distant maîtrisé. Le bon critère n’est pas une promesse générale de vitesse ou d’économie, mais la capacité à satisfaire vos exigences d’environnement, d’accès, de traçabilité et de reprise.

Pour concevoir le passage, décrivez le contrat entre les deux côtés : quel événement démarre la tâche, quel commit est concerné, quels fichiers ou résultats sont transmis, et quel statut autorise l’étape suivante ? Gardez les déclencheurs séparés tant que vous n’avez pas vérifié que les deux environnements interprètent les résultats de la même manière. Un build annulé dans Xcode Cloud ne doit pas déclencher une étape suivante qui attend un artefact jamais produit.

Faites ensuite un essai de bout en bout. Comparez l’origine du déclenchement, le commit, les journaux, les états du workflow et le résultat remis à l’étape suivante. Pour les tâches qui restent dans Xcode Cloud, vérifiez les résultats dans son historique. Pour celles confiées à un Mac géré par l’équipe, documentez les accès, la conservation des données, les mises à jour et la procédure de reprise. La comparaison doit s’appuyer sur des exécutions observées, et non sur une estimation non vérifiée des performances ou du coût.

Si votre équipe évalue un nœud Mac distant pour une tâche temporaire, un test d’intégration ou une capacité de CI à gérer directement, vous pouvez examiner les modalités de location d’un Mac mini distant avec MACCOME. Ce choix ne convient pas automatiquement à une charge lourde permanente ni aux tâches qui exigent une interface physique locale : dans ces cas, un Mac détenu et administré sur place peut mieux répondre aux contraintes. Pour une équipe qui teste plusieurs options d’accès, le site MACCOME en français permet de consulter les informations disponibles avant de définir un essai.

Mettre la politique en production sans perdre la preuve

Avant d’appliquer le réglage à tous les workflows, consignez une politique par usage. Une validation de branche peut annuler une exécution si le résultat plus récent est celui qui compte. Un workflow de diagnostic doit préserver les résultats dont l’équipe a besoin pour isoler une panne. Une publication doit protéger les artefacts et les états de livraison requis. Cette séparation rend la configuration compréhensible par les développeurs comme par les personnes chargées de la mise en production.

Pour chaque workflow, inscrivez son objectif, ses conditions de démarrage, la règle d’annulation et le résultat attendu. Faites valider le cas d’annulation par un essai contrôlé, puis vérifiez que les tableaux de bord et les procédures d’intégration n’interprètent pas le statut « annulé » comme un succès. Enfin, répétez l’acceptation après toute modification de déclencheur ou de séquence d’actions, puisque le comportement de la chaîne dépend de sa configuration réelle.

L’annulation automatique des builds Xcode Cloud est utile quand elle retire une validation dépassée sans retirer une preuve nécessaire. Si vous devez compléter cette CI par un nœud Mac, commencez par un essai limité à une tâche non critique, avec un commit identifiable et des critères d’acceptation vérifiables. Vous pourrez alors comparer votre workflow actuel à un Mac géré par votre équipe sans supposer que la location convient aux besoins de publication permanente, aux charges constantes ou aux exigences d’interface locale.