Pour celles et ceux qui gèrent le pipeline et la machine

Nous avons déplacé notre machine de build du bureau vers un centre de données

Après une fusion de code, votre priorité devrait être de vérifier le résultat du build, pas de savoir si le bureau est toujours alimenté. OSXPort héberge des Mac mini physiques dédiés pour les responsables CI : le centre de données s’occupe de l’alimentation, du réseau et du refroidissement, tandis que votre équipe garde la maîtrise de ses projets et de son rythme de publication.

Louez une machine de build iOS pour une journée de test Comparer les trois configurations et les tarifs

À partir de $19.7/jour, facturation en USD. Testez votre pipeline avant de décider d’une migration durable.

Planning des builds de l’équipe Un nœud physique, planifié selon vos règles

Les branches partagent la machine de votre équipe, sans concurrence avec les builds d’autres clients.

Branche Exemple d’ordre des builds
main
Vérification de fusion
release/2.4
Packaging et archivage
nightly
Tests nocturnes
Disponible 365 jours par an Le centre de données gère l’alimentation, le réseau et le refroidissement ; l’équipe définit la concurrence et l’ordre d’exécution des tâches.
Ce schéma illustre une organisation possible, pas une mesure du temps de build ni un relevé historique de disponibilité. Le Mac mini entier est attribué à un seul client ; il ne s’agit pas d’une machine virtuelle.
Clarifier les responsabilités compte plus que d’acheter une machine supplémentaire

Le centre de données gère l’infrastructure, l’équipe garde la main sur les publications

Une machine gérée en interne, un runner partagé ou une machine dédiée hébergée peuvent tous exécuter vos builds. La différence tient à la personne chargée de maintenir la machine disponible et à votre besoin de conserver un environnement actif en continu. Nous nous adressons aux équipes qui fusionnent du code plusieurs fois par jour et veulent réduire la gestion du matériel, sans pour autant recommander la location pour chaque besoin de packaging.

Ce que gère le centre de données

L’alimentation, la connexion réseau et le refroidissement font partie de l’environnement hébergé. Le nœud fonctionne 365 jours par an ; les tâches nocturnes ne dépendent plus de l’interrupteur ou de la climatisation du bureau.

Les responsables ont ainsi moins de tâches sans rapport avec le code à gérer, mais cela ne garantit pas la réussite de chaque build. Les téléchargements de dépendances, les résultats des tests et la configuration du projet doivent toujours être diagnostiqués séparément.

Ce que l’équipe garde en charge

L’équipe configure et gère le code, l’enregistrement des runners, les versions des outils, les éléments de signature, le nombre de tâches simultanées et les artefacts de build. L’interface graphique de macOS et la ligne de commande sont pleinement accessibles ; vos workflows existants peuvent être intégrés selon les pratiques habituelles.

Vous devez sauvegarder vous-même les certificats de signature, la configuration du projet et les artefacts essentiels. Le cache accélère la préparation des builds répétitifs, mais ne remplace pas une sauvegarde restaurable du projet et des identifiants.

Ce que nous traitons ensemble en cas d’incident

En cas de problème de connexion au nœud, commencez par distinguer un souci réseau, système ou lié à la tâche. Si vous suspectez une panne matérielle, ouvrez un ticket depuis la console en indiquant l’identifiant du nœud, l’heure et les symptômes ; nous lancerons les vérifications et, si nécessaire, le remplacement de la machine.

Après un remplacement, vérifiez à nouveau la configuration du runner, des outils et de la signature. Documenter à l’avance les étapes de reprise est plus fiable que de supposer que la machine ne rencontrera jamais de problème.

Consulter les procédures d’incident et le guide de sauvegarde
Ressources dédiées ne signifie pas concurrence illimitée

Gardez la maîtrise de votre environnement, en tenant compte des limites d’une machine unique

Choisir une machine physique dédiée permet de savoir clairement à qui appartiennent les ressources et de mieux comprendre les changements de l’environnement. Cela élimine la concurrence avec d’autres clients sur la même machine, mais pas les variations dues à la taille des projets, au nombre de tâches ou aux services dont elles dépendent.

Une machine entière pour un seul client

Le processeur, la mémoire unifiée et le SSD sont consacrés à vos charges de travail. Votre équipe gère DerivedData, les dépendances et le cache des projets ; les builds d’autres clients ne les suppriment pas.

Si la durée des tâches varie, vous pouvez examiner les changements du projet, l’efficacité du cache, le périmètre des tests et la concurrence sur la machine, plutôt que de vous demander si une tâche inconnue utilise les ressources.

La gestion des files d’attente reste à concevoir

Plusieurs branches d’une même équipe peuvent toujours se disputer les ressources d’un seul nœud. Lancer toutes les tâches en même temps n’augmente pas la puissance de calcul ; définissez le nombre de runners simultanés en fonction de la mémoire utilisée et des priorités de publication.

Un nœud unique est moins flexible qu’une solution partagée que l’on peut faire évoluer à la demande. Pour des builds occasionnels ou des pics très courts et imprévisibles, un runner partagé peut mieux convenir. Si vous avez déjà un Mac inutilisé et ne créez qu’un ou deux packages par mois, l’autohébergement peut aussi coûter moins cher.

Notre conseil : commencez par migrer un pipeline, pas toute l’équipe.

Avec le même code, comparez le temps de récupération, de préparation des dépendances, de compilation, de test et de téléversement. Vous pourrez ainsi déterminer si le goulot d’étranglement vient des ressources de calcul, du réseau ou de la conception des tâches. Une machine dédiée clarifie l’attribution des ressources ; elle ne résout pas tous les problèmes de build.

Choisissez une configuration adaptée à votre charge de travail

Trois configurations pour choisir en connaissance de cause

Apple Silicon M4 convient aux builds légers et au développement courant. Le M4 Pro offre une autre option pour les projets plus importants et les besoins en mémoire plus élevés. Nous indiquons précisément la puce, la mémoire unifiée et le SSD, plutôt que de nous contenter de niveaux vagues, et ne promettons pas qu’une configuration accélérera tous les projets dans les mêmes proportions.

Port M4 Base

Apple Silicon M4 · 16GB de mémoire unifiée · SSD 256GB

Convient à une seule app, à quelques builds par jour ou pour vérifier d’abord la faisabilité d’un build à distance. Il n’est pas recommandé de lancer plusieurs simulateurs et de nombreuses compilations en parallèle.

$19.7/jour · $98.5/mois

À la semaine : $53.2 · Au trimestre : $267.9

Louer Port M4 Base

Port M4 Plus

Apple Silicon M4 · 24GB de mémoire unifiée · SSD 512GB

Convient aux builds après fusion, aux tâches sur plusieurs branches et aux tests avec simulateur. Ajustez le nombre de tâches simultanées en fonction du pic de mémoire réel du projet, plutôt que de le régler au maximum d’emblée.

$40.3/jour · $201.6/mois

À la semaine : $108.9 · Au trimestre : $548.4

Louer Port M4 Plus

Port M4 Pro

Apple Silicon M4 Pro · 64GB de mémoire unifiée · SSD 2TB

Convient aux projets comportant de nombreuses targets, aux tâches gourmandes en mémoire et aux essais d’inférence de modèles en local. Si votre charge de travail nécessite un entraînement sur plusieurs cartes graphiques, un Mac mini ne remplace pas le matériel adapté.

$61.4/jour · $307.1/mois

À la semaine : $165.8 · Au trimestre : $835.3

Louer Port M4 Pro

Les tarifs indiqués sont les prix de base du nœud et sont facturés en USD. Les options, comme l’extension du stockage, sont facturées séparément. La configuration complète et le montant final sont confirmés lors de la commande.

Comparer les configurations selon votre projet
Intégrez le réseau à vos critères de choix

Cinq régions : commencez par situer vos dépôts et vos dépendances

Singapour, Japon (Tokyo), Corée du Sud (Séoul), Hong Kong et côte ouest des États-Unis : cinq régions couvrant l’Asie-Pacifique et l’ouest de l’Amérique du Nord. Les trois configurations sont proposées dans ces cinq régions. Vérifiez leur disponibilité en temps réel dans la console. Pour choisir une région, tenez compte non seulement de la distance entre l’équipe et le nœud, mais aussi du parcours complet du code, des dépendances et des artefacts.

Singapour

Un premier choix à évaluer pour les équipes d’Asie du Sud-Est. Testez ensemble votre dépôt de code et vos sources de dépendances habituelles pour voir si la préparation représente l’essentiel du temps d’exécution.

Choisir le nœud de Singapour

Japon (Tokyo)

Une région à envisager pour les équipes collaborant au Japon et en Asie de l’Est. Si vous utilisez souvent la machine à distance, évaluez aussi bien l’interactivité que le parcours de téléversement.

Choisir le nœud de Tokyo

Corée du Sud (Séoul)

À comparer pour les équipes d’Asie du Nord-Est. Utilisez le même commit et les mêmes versions de dépendances pour ne pas confondre les effets du cache avec les différences entre régions.

Choisir le nœud de Séoul

Hong Kong

Une région à évaluer pour les équipes collaborant depuis le sud de la Chine et l’Asie du Sud-Est. Les performances des connexions entre réseaux peuvent varier selon l’opérateur ; testez vos propres projets pour prendre votre décision.

Choisir le nœud de Hong Kong

Côte ouest des États-Unis

À évaluer en priorité si vos dépôts, vos sources de dépendances et les connexions de votre équipe se trouvent sur la côte ouest nord-américaine. Si l’équipe est dispersée, choisissez en fonction des principaux flux de données du pipeline.

Choisir le nœud de la côte ouest des États-Unis

Ces indications aident à choisir une région ; elles ne correspondent pas à des mesures de latence ville par ville. Pour une équipe répartie entre plusieurs régions, mesurez d’abord les temps de récupération et de téléversement avant de déplacer le nœud. Un nom de région ne remplace pas un test.

Nos réponses aux questions s’appuient sur les mêmes principes

Trois principes qui guident la présentation de notre service

Les responsables CI ont besoin d’informations concrètes pour prendre une décision. Nous distinguons le catalogue, les cas d’usage et les modalités de paiement afin que les conditions essentielles soient claires avant la mise en service.

  1. 01

    Configuration et prix détaillés

    La puce, la mémoire unifiée, le SSD et les quatre périodes de facturation sont indiqués séparément. Les nœuds de base et les options sont tarifés distinctement ; le prix mensuel n’est pas présenté comme un tarif journalier, et les mentions « haut de gamme » ne remplacent pas une configuration précise. Vérifiez d’abord les ressources, puis le coût de toute la période d’utilisation.

  2. 02

    Nous vous le disons si le service ne convient pas

    Si vous avez déjà un Mac inutilisé et que vous créez rarement des builds, l’autohébergement peut être plus économique. Pour des pics courts et variables, un runner partagé peut offrir plus de souplesse. Les étapes de débogage qui nécessitent un appareil physique local ne devraient pas non plus dépendre uniquement d’un nœud distant. L’hébergement dédié convient à un usage régulier, sans remplacer toutes les méthodes de développement.

  3. 03

    Facturation transparente en USD

    Seuls USDT-TRC20 et Visa / Mastercard / Amex (via Stripe) sont acceptés. Les moyens de paiement réellement disponibles sont ceux renvoyés par l’interface serveur. Avant de commander, vérifiez le modèle, la région, la période et les options. Pour les questions de paiement ou de facturation, ouvrez un ticket depuis la console ; pour toute question avant achat, écrivez à support@osxport.com.

Demander conseil avec les détails de votre pipeline

Décidez après un build complet

Commencez par récupérer le code, préparer les dépendances, compiler, tester et archiver. Notez la durée et le pic de mémoire, puis choisissez la configuration, le niveau de concurrence et la période. L’essai à la journée commence à $19.7/jour : inutile de vous engager tout de suite dans un environnement à long terme.

Si vous avez déjà une machine inutilisée et ne créez qu’un ou deux packages par mois, nous vous conseillons aussi de calculer le coût de l’autohébergement.

Louez une machine de build iOS pour une journée de test Voir toutes les offres et options