Ces workflows ne sont ni des témoignages clients ni des promesses de résultats non vérifiés. Ils distinguent les déclencheurs, les tâches sur machine physique dédiée, les responsabilités liées à la signature, l’emplacement des journaux et la destination des artefacts. Votre équipe peut ainsi les adapter à ses dépôts et à son modèle d’autorisations.
Ces architectures décrivent uniquement le flux des tâches. Les autorisations du dépôt, les éléments de signature, le compte développeur, la validation des versions et la durée de conservation des artefacts restent à définir par l’équipe utilisatrice.
Fixez les versions de Xcode et des Command Line Tools, les fichiers de verrouillage des dépendances et les commandes de nettoyage. Avant tout changement de version, validez-le dans un répertoire de travail distinct, puis faites-le entrer dans la file principale.
Versions et fichiers de verrouillageInjectez les jetons, certificats et profils de provisionnement par un mécanisme contrôlé. Ne conservez dans les journaux que les informations utiles au diagnostic et supprimez les chemins, jetons et adresses de dépôts privés avant leur diffusion.
Privilèges minimauxNommez séparément les archives, packages exportés, fichiers de symboles et rapports de test, en leur associant l’identifiant du commit. Une fois le transfert terminé, supprimez les copies temporaires du nœud conformément aux règles de l’équipe.
Export contrôléCe workflow permet d’enregistrer CDNMac M4 comme runner auto-hébergé. Un événement du dépôt lance la tâche, puis les artefacts produits sont transmis à l’équipe pour validation ou à son système de distribution.
La branche principale ou un tag de version lance la file. La tâche consigne d’abord le hash du commit, la branche, le déclencheur et le Scheme cible, sans afficher de variables sensibles dans les journaux.
Destination : répertoire de travail isolé sur machine physique dédiéeRestaurez les dépendances Swift Package, CocoaPods ou autres à partir des fichiers de verrouillage. La clé de cache doit inclure au minimum leur empreinte et la version des outils pour éviter qu’un ancien cache ne contamine une autre version.
Destination : répertoire de cache versionné et journaux des dépendancesLancez l’archivage en précisant le workspace, le scheme, la configuration et la destination. En cas d’échec, conservez le code de sortie, les journaux essentiels et le bundle de résultats.
Destination : répertoire d’archive associé au commitVérifiez la correspondance entre le Bundle Identifier, l’équipe, la validité du certificat et le profil de provisionnement. Le compte développeur et les éléments de signature restent gérés par l’équipe utilisatrice.
Destination : liste de contrôle, sans identifiants en clairExportez le package d’installation, les fichiers de symboles, le résumé du build et les sommes de contrôle, puis copiez-les dans un espace de stockage contrôlé par l’équipe. Supprimez le répertoire temporaire une fois le transfert confirmé.
Destination : stockage contrôlé et file de validation de l’équipeUne machine dédiée ne signifie pas que toutes les tâches s’exécutent en parallèle. Avec un seul CDNMac M4, mieux vaut définir clairement les priorités, les répertoires de travail et les règles de nettoyage afin d’éviter les interférences entre les tâches de publication et les vérifications courantes.
Après chaque fusion, lancez les tests unitaires, les contrôles statiques et un archivage de base. Le cache peut être réutilisé, mais isolez DerivedData par projet et par version de Xcode.
À son entrée dans la file, suspendez les tâches non essentielles du même dépôt. Utilisez une configuration distincte pour la vérification de signature et l’export, et demandez à l’équipe de valider le résumé des artefacts.
Insérez la tâche dans la file après validation du responsable. Ne restaurez que le cache nécessaire au diagnostic. Une fois le build terminé, supprimez les variables temporaires et consignez le point de référence pour le retour arrière.
Une tâche de publication ne préempte pas une tâche qui écrit des artefacts. En cas d’échec, collectez les journaux avant de libérer le répertoire de travail. À la fin de chaque tâche, lancez un nettoyage idempotent.
Avec Flutter iOS, les temps d’attente se répartissent souvent entre la restauration des dépendances, CocoaPods et le build Xcode. En séparant ces étapes, l’équipe peut vérifier l’efficacité du cache et identifier la couche à l’origine d’un échec.
Chaque étape produit ses propres journaux et code de sortie. L’étape suivante ne lit ses artefacts que si la précédente réussit, ce qui évite de confondre un problème de dépendances avec un échec de compilation Xcode.
Restaurez les dépendances du projet et consignez la version du SDK ainsi que l’empreinte du fichier de verrouillage.
Installez les dépendances iOS natives à partir de Podfile.lock, sans réutiliser un répertoire Pods incompatible.
Lancez l’archive en précisant le workspace, le scheme et la configuration.
Après vérification de la signature, exportez les artefacts et générez l’identifiant du commit ainsi que l’empreinte de contrôle.
Un accès au cache signifie uniquement que le répertoire et la clé correspondants peuvent être réutilisés ; il ne garantit pas un build complet plus rapide. Après une mise à jour de Flutter, CocoaPods, Xcode ou des fichiers de verrouillage, vérifiez à nouveau les limites du cache.
Le Mac cloud génère et vérifie les artefacts du build, sans remplacer la validation des versions par l’équipe. Le compte développeur, les éléments de signature, les informations de version et la décision de distribution restent sous la responsabilité de l’utilisateur.
La branche de publication produit une archive et un export accompagnés du hash du commit, du numéro de version, du numéro de build, des fichiers de symboles et de l’empreinte de contrôle.
Le responsable vérifie le périmètre des changements, la correspondance de la signature, les informations relatives à la confidentialité, l’usage des autorisations et les résultats des tests. En cas de refus, relancez le build à partir du commit concerné.
Après validation, la tâche de publication contrôlée par l’équipe utilise des identifiants à privilèges limités pour effectuer l’envoi. Ne stockez pas de données sensibles dans le dépôt ni dans les journaux de build ordinaires.
Conservez l’identifiant des artefacts, la décision de validation et les journaux nécessaires. Une fois le transfert terminé, supprimez du nœud les fichiers exportés et identifiants temporaires.
CDNMac M4 offre une puce M4, 16 Go de RAM et un SSD de 256 Go. Il convient aux tests de compatibilité de modèles locaux et au prototypage. Vérifiez d’abord les besoins du modèle, du contexte, des données et de la mémoire.
Ne synchronisez que le sous-ensemble nécessaire à l’expérimentation et consignez son origine et sa version. Anonymisez les données sensibles et utilisez des répertoires distincts pour les données sources, les fichiers intermédiaires et les résultats.
Consignez les versions de macOS, du runtime, du framework et du format du modèle. Commencez par un petit échantillon pour vérifier le chargement, l’inférence et l’usage mémoire avant d’élargir l’expérimentation.
Fournissez les paramètres de l’expérience, un résumé des résultats et les journaux nécessaires, sans inclure l’ensemble des données sensibles dans le rapport. Avant la fin de la location, copiez les résultats utiles dans un stockage contrôlé.
Si le modèle, le contexte et les données intermédiaires ne fonctionnent pas de manière stable avec 16 Go de RAM, ou si vous avez besoin d’une configuration de puce ou de mémoire non répertoriée, contactez d’abord l’équipe de service pour vérifier sa disponibilité. La réussite d’un prototype ne garantit pas une capacité adaptée à la production.
Demander conseil sur la configurationVoici des exemples de formulations par rôle, utilisables lors d’un bilan interne. Ils ne constituent ni des avis de clients particuliers, ni des évaluations, ni une approbation d’entreprise.
« Ce qui m’importe, c’est que la file soit réservée à notre équipe et que les journaux permettent de diagnostiquer les échecs. Définir clairement le répertoire de travail et la destination des artefacts est plus utile que de parler vaguement de vitesse de build. »
Responsable mobile
« Quand des tâches de plusieurs branches partagent la même machine physique, il faut surtout définir les priorités, les clés de cache et les règles de nettoyage. Les ressources dédiées assurent une base d’isolation, mais c’est à nous de définir le pipeline. »
Ingénieur plateforme CI
« En cas de connexion depuis différents fuseaux horaires, je veux que l’accès à distance, les builds en arrière-plan et l’export des artefacts soient indépendants. Ainsi, une brève instabilité du réseau local ne change rien à une tâche de build en cours. »
Développeur indépendant
Avant de reprendre ces étapes, commencez par créer une version minimale fonctionnelle. Vous pouvez adapter les noms des variables d’environnement aux conventions de l’équipe, mais ne transmettez aucune valeur sensible au dépôt ni directement aux journaux de build.
| Workflow | Prérequis | Variables d’environnement | Point de retour en cas d’échec |
|---|---|---|---|
| Build automatisé d’apps | Accès au dépôt, version de Xcode, Scheme, fichier de verrouillage des dépendances, configuration d’export | REPO_REF BUILD_SCHEME EXPORT_PATH |
Conserver le bundle de résultats et l’identifiant du commit, supprimer le trousseau temporaire et revenir au dernier commit compilable |
| Build multi-branches | Priorité des branches, répertoires de travail distincts, limite de concurrence, script de nettoyage idempotent | BRANCH_NAME RUN_PRIORITY WORK_ROOT |
Arrêter les tâches suivantes, sauvegarder les journaux en cours, rétablir un arbre de travail propre et l’ordre initial de la file |
| Flutter iOS | Version de Flutter, Podfile.lock, workspace Xcode, règles des clés de cache | FLUTTER_ROOT PODS_CACHE_KEY IOS_SCHEME |
Invalider le cache étape par étape, conserver les journaux réutilisables et reprendre depuis la dernière étape validée |
| Livraison TestFlight | Validation de publication, informations de version, vérification de signature, contrôle des artefacts et identifiants contrôlés par l’équipe | RELEASE_VERSION BUILD_NUMBER ARTIFACT_PATH |
Arrêter la tâche de distribution, révoquer les identifiants temporaires, revenir à la liste de validation et régénérer un candidat |
| Expérimentation IA | Format du modèle, petits échantillons de données, version du runtime, suivi de la mémoire et répertoire d’export | MODEL_PATH DATASET_PATH RESULT_PATH |
Conserver la liste des paramètres et le résumé des résultats, rétablir les dépendances figées et revenir à la copie en lecture seule des données sources |
Limitez-vous à un dépôt, un Scheme et une destination de sortie pour vérifier que le nœud peut effectuer le workflow de bout en bout.
Injectez des identifiants à privilèges minimaux par un mécanisme contrôlé, puis vérifiez l’anonymisation des journaux ainsi que les procédures d’expiration et de rotation.
Avant d’ajouter d’autres branches, définissez les priorités, les délais d’expiration, la récupération après échec et les règles de nettoyage des répertoires de travail.
Choisissez d’abord la durée de location et le nœud, puis suivez le guide pour vérifier la connexion, l’environnement Xcode, les autorisations du dépôt et votre première archive. La disponibilité réelle et les informations de livraison sont celles affichées en temps réel dans la console.