21 méthodes de déploiement, dont 10 embarquent votre code.
Un scénario d'usage sur cette plateforme n'est pas une catégorie marketing, c'est un nom de méthode. config.json déclare exactement 21 méthodes dont le nom commence par deploy_, config_dev.json déclare les 21 mêmes, et chaque forme de déploiement proposée par Xuda correspond à l'une de ces entrées. Dix d'entre elles publient une version de votre projet, et un champ vous indique lesquelles : ce sont les entrées qui prennent data.release_doc_id. Les onze autres provisionnent de l'infrastructure ou écrivent un enregistrement. Ces mêmes dix méthodes définissent toutes req.data.deploy_type et transmettent l'appel à une fonction partagée unique, deploy_app, qui n'est elle-même pas déclarée dans cpi_methods : il n'existe donc pas d'appel de déploiement générique. Vous choisissez une porte d'entrée par son nom, et le code partagé qui se trouve derrière lit le type directement sur la requête. Le plancher de plan est inscrit sur chaque entrée plutôt que sur une page tarifaire : deploy_mini_app est la seule méthode de tout le catalogue de 1010 entrées à porter min_plan free, douze méthodes deploy_ portent min_plan pro, deux portent agency, et six ne portent aucun min_plan, ce qui signifie que tout le monde franchit cette barrière. En ne comptant que la barrière de plan, 7 des 21 sont accessibles en Free, 19 en Pro, 19 en Team et 21 en Agency, pour des prix d'abonnement de 0 $, 49 $, 149 $ et 399 $ par mois. Cette page parcourt les huit scénarios avec lesquels les utilisateurs arrivent réellement, nomme la méthode que chacun résout, et nomme ceux qui ne résolvent rien.
Le scénario avec lequel vous arrivez, et la méthode qu'il résout.
Personne n'arrive en demandant deploy_spa. Les utilisateurs arrivent avec une idée en tête : une application pour leurs clients, un site sans code derrière, une tâche qui s'exécute à trois heures du matin, une copie pour tester. Chacune de ces idées correspond à une ou deux entrées nommées dans cpi_methods, et cette correspondance est fixée au moment de l'appel plutôt que choisie à l'exécution. Lisez chaque ligne comme une alternative, et les puces qui l'accompagnent comme les appels qu'elle vous coûte réellement.
Méthodes dont le nom commence par deploy_
Parmi elles, accessibles avec un compte Free
Méthodes soumises à Pro dans le catalogue qui sont des déploiements
Méthodes de déploiement soumises à Team
Ce qu'un appel de déploiement vous demande, et ce qu'il en fait.
Les 21 entrées ne partagent pas la même signature, mais quatre champs de la déclaration vous en disent presque tout sur une entrée donnée avant même d'ouvrir son gestionnaire : si elle prend un identifiant de version, si elle prend une région, si elle s'exécute comme une tâche suivie, et quel script cette tâche exécute. Deux champs supplémentaires déterminent qui peut l'appeler. 14 des 21 exigent clearance admin et 7 exigent clearance user, et 20 des 21 portent private: true, l'indicateur qu'aucune clé API externe ne franchit, quel que soit le mode. Le déploiement est une action d'opérateur menée depuis une session connectée, pas quelque chose qu'une intégration déclenche.
- Un identifiant de version, ou rien. 10 des 21 prennent data.release_doc_id, et ce sont exactement les dix qui publient une version de votre projet. Six d'entre elles se lient à un seul programme Studio via un data.prog_id obligatoire : embed, mini_app, preview, pwa, spa et user_group. deploy_mpa prend data.route_id à la place. Les onze autres méthodes provisionnent de l'infrastructure ou écrivent un enregistrement, sans jamais toucher à une version.
- Une région, la plupart du temps. 16 des 21 acceptent une région. Les cinq qui n'en acceptent pas sont instance, marketplace, mini_app, site et static_website. Deux d'entre elles écrivent un document dans xuda_master sans provisionner de serveur, deux publient des fichiers vers le stockage, et la cinquième est le déploiement gratuit, qui n'accepte ni région ni aucun champ create_datacenter.
- Une tâche, la plupart du temps. 14 des 21 s'exécutent comme une tâche suivie avec un job_timeout de 1 800 000 ms, soit 30 minutes, et rapportent leur progression via leurs job_steps déclarés. Les sept autres répondent sans créer de tâche : another, datacenter, instance, marketplace, site, static_website et xucode. Un appel qui répond immédiatement effectue de la paperasse, pas du provisionnement.
- Un seul script, neuf fois. api, cron, embed, emitter, mpa, preview, pwa, spa et user_group exécutent un script identique en 12 étapes, avec le nom du type substitué : lancement du processus, puis création, pare-feu, plan de sauvegarde, connexion et installation pour le serveur datacenter, puis les cinq mêmes étapes pour le serveur de déploiement, puis activation du serveur. Un seul appel crée donc deux serveurs, pas un, à moins de passer data.app_datacenter pour réutiliser un datacenter déjà existant. Ce champ est optionnel, tout comme les champs create_datacenter qui l'accompagnent.
Quatre tarifs, et seuls deux d'entre eux changent ce que vous pouvez déployer.
La barrière de plan tient en quatre lignes de calcul. isValidPlan, dans cpi/http_module/index.mjs aux lignes 542 à 547, lit min_plan sur l'entrée de configuration, renvoie true quand la clé est absente, et compare sinon deux rangs dans PLAN_OBJ : free 0, pro 1, team 2, agency 3. Appliqué aux 21 méthodes deploy_*, voilà tout le tableau. Le catalogue compte 19 méthodes soumises à Pro, et 12 d'entre elles sont des deploy_*, donc un abonnement Pro se dépense en grande partie ici même. Et une seule méthode sur les 1010 entrées porte min_plan free, deploy_mini_app, le seul déploiement qu'un compte gratuit peut lancer. Les prix sont mensuels.
Free, 0 $ | Pro, 49 $ | Team, 149 $ | Agency, 399 $ | |
|---|---|---|---|---|
| Méthodes deploy_* franchissant la barrière de plan | 7 sur 21 | 19 sur 21 | 19 sur 21 | 21 sur 21 |
| Ce que ce palier ajoute par rapport au précédent | les 6 méthodes sans aucun min_plan déclaré, plus deploy_mini_app | 12 : another, api, cron, datacenter, embed, emitter, load_balancer, mpa, preview, pwa, spa, user_group | rien. Aucune méthode deploy_* ne porte min_plan team | deux : deploy_instance et deploy_marketplace, qui écrivent toutes deux un document dans xuda_master sans provisionner de serveur |
| Déploiements embarquant une version de votre projet, ceux qui prennent data.release_doc_id | 1 sur 10, deploy_mini_app | 10 sur 10 | 10 sur 10 | 10 sur 10 |
| Un lien que vous partagez : spa, pwa, embed, preview | non, les quatre sont en Pro | oui, une tâche de 12 étapes chacune | les 4 mêmes qu'en Pro | les 4 mêmes qu'en Pro |
| Un VPS, un serveur web, ou un VPS full stack avec la CLI xuda dessus | oui, les trois ne déclarent aucun min_plan | oui | oui | oui |
| haproxy devant vos déploiements de même type | non | deploy_load_balancer, 6 étapes | oui | oui |
| Un second environnement d'une application que vous exploitez déjà | non | deploy_another, nouveau nom, nouvelle région et nouveau type de serveur | oui | oui |
Un appel de déploiement, trois destinations, et la première construit deux serveurs.
Dix des 21 méthodes déploient une version de votre projet. Ce sont celles qui prennent data.release_doc_id, elles définissent toutes req.data.deploy_type, et elles transmettent toutes l'appel à une fonction partagée unique, deploy_app, dans cpi/deploy_module/index.mjs ligne 116. deploy_app n'est pas elle-même déclarée dans cpi_methods, donc il n'existe pas d'appel de déploiement générique : vous choisissez une porte d'entrée, et la porte d'entrée nomme le type. Les 11 autres provisionnent une machine ou écrivent un enregistrement. Lisez la première branche deux fois, car un simple appel deploy_spa provisionne un serveur datacenter avant de provisionner le vôtre.
Trois étapes, et celle du milieu est une barre de progression que vous regardez.
Pas un assistant guidé. Ce que l'entrée de configuration vous demande de fournir, ce que la tâche rapporte en retour, et ce que vous détenez quand la dernière ligne affiche activation du serveur.
- 01
Choisissez la porte d'entrée, la version et le programme
Il n'existe aucun appel de déploiement générique. deploy_app est partagée par les 10 méthodes de publication mais n'est pas déclarée dans cpi_methods, donc vous appelez deploy_spa, deploy_pwa, deploy_embed, deploy_preview et ainsi de suite, et ce choix définit deploy_type pour vous. Chacune des 10 prend data.release_doc_id, la version en cours de publication. Six d'entre elles, embed, mini_app, preview, pwa, spa et user_group, prennent aussi un data.prog_id obligatoire nommant le programme Studio unique auquel le déploiement se lie, et deploy_mpa prend data.route_id à la place. La région est un champ sur 16 des 21.
- 02
Suivez le script déclaré s'exécuter
job_steps n'est pas une machine à états interne, c'est le texte de progression littéral. 14 des 21 enregistrent une tâche suivie avec job_timeout 1 800 000 ms, un plafond de 30 minutes. Un déploiement de type lien rapporte 12 lignes, deploy_mini_app 11, deploy_full_stack_vps 8, deploy_vps et deploy_webserver 7 chacun, deploy_load_balancer 6. Les 7 autres ne déclarent aucune étape et répondent sans créer de tâche : another, datacenter, instance, marketplace, site, static_website et xucode.
- 03
Prenez possession du serveur activé
La dernière étape de chaque script de provisionnement est l'activation du serveur, et ce que vous détenez après elle est une machine avec la région, le pare-feu et le plan de sauvegarde définis par ce même script. À partir de là, deploy_load_balancer place haproxy devant plusieurs déploiements de même type avec contrôles de santé et basculement, et deploy_another redéploie l'application entière sous un nouveau nom, une nouvelle région et un nouveau type de serveur, avec répercussion sur ses déploiements enfants. Les deux sont en min_plan pro.
Douze lignes, dont six concernent une machine que vous n'avez jamais nommée.
Le tableau job_steps de deploy_spa dans l'ordre, exactement comme config.json le déclare et comme la barre de progression le lit. Les mêmes 12 lignes, avec le nom du type substitué, sont déclarées sur deploy_api, deploy_cron, deploy_embed, deploy_emitter, deploy_mpa, deploy_preview, deploy_pwa et deploy_user_group. Lisez d'abord les lignes 02 à 06 : elles concernent un serveur datacenter.
Huit limites, dont trois méthodes déclarées qui refusent toujours de s'exécuter.
- Router ne se déploie pas. deploy_mpa est déclarée, soumise à Pro, et définit req.data.deploy_type sur mpa, une valeur absente du tableau deploy_type dans config.json, donc deploy_app la refuse avec le code -2 dans cpi/deploy_module/index.mjs aux lignes 139 à 141. config_dev.json liste bien mpa, et la liste aussi comme beta, donc elle est refusée quatre lignes plus loin à la place. Un déploiement de routeur multi-pages n'est pas quelque chose que vous pouvez démarrer aujourd'hui.
- Emitter est en beta dans la configuration de production. La chaîne emitter figure dans deploy_type_in_beta dans config.json, donc deploy_app renvoie le code -2 dans cpi/deploy_module/index.mjs aux lignes 143 à 144. config_dev.json l'a retirée de cette liste, ce qui signifie que le modèle de flux de changements fonctionne sur dev et est refusé dans la copie du dépôt. La méthode est déclarée et le pipeline de provisionnement derrière elle est le même que celui utilisé par cron. La barrière tient en une seule entrée de tableau.
- Aucune méthode ne construit de binaire iOS, Android ou macOS. deploy_ios, deploy_android et deploy_macos existent dans cpi/deploy_module/index.mjs aux lignes 1388 à 1405, et aucun des trois n'est déclaré dans cpi_methods, donc rien de ce qui arrive via /cpi ne peut les atteindre. L'ancien modèle d'application mobile est abandonné plutôt que reporté.
- Il n'existe aucun type de déploiement pour la collaboration en temps réel. Aucune des 21 méthodes ne provisionne de websocket, de canal de présence ou de surface CRDT. Ce qui s'en rapproche le plus dans l'ensemble, deploy_emitter, est un traitement batch côté serveur déclenché par un flux de changements de base de données, et il est refusé en tant que beta de toute façon.
- MCP Server figure comme type de déploiement dans les deux configurations, se trouve dans deploy_type_in_beta dans les deux, et n'a aucune entrée deploy_mcp dans cpi_methods, donc il n'y a rien à appeler même avant la barrière beta. Un déploiement MCP par projet n'existe pas.
- Team coûte 149 $ contre 49 $ pour Pro, et n'apporte rien sur cette page. Zéro méthode deploy_ ne porte min_plan team, donc Pro et Team atteignent toutes deux 19 des 21. Agency à 399 $ ajoute exactement deux méthodes de plus, deploy_instance et deploy_marketplace, qui créent toutes deux un document dans xuda_master sans provisionner de serveur.
- deploy_xucode est la seule entrée deploy_ sans clé de microservice, et http_module renvoie tôt sur un microservice manquant dans cpi/http_module/index.mjs aux lignes 942 à 944, donc l'appel n'atteint jamais son gestionnaire dans cpi/deploy_module/index.mjs ligne 1777. C'est aussi la seule des 21 à omettre private.
- Un déploiement de site statique n'exécute aucun code. deploy_static_website lit un dossier drive et le transmet à deploy_site, qui envoie les fichiers sur R2 et bascule un pointeur KV de façon atomique. Aucun serveur, aucun cron, aucune API, aucune base de données. Un gestionnaire de formulaire ou une tâche planifiée constitue un second déploiement sur un second serveur.
Ce qui est réellement déployable aujourd'hui
Six réponses tirées directement de config.json et de cpi/deploy_module/index.mjs, plutôt que de l'assistant guidé posé au-dessus.
Observez un déploiement se dérouler.
Douze étapes, deux serveurs et un identifiant de tâche avec un délai d'expiration de 30 minutes. Le même script exécuté par neuf des 21 méthodes, avec le nom du type substitué.
Lisez la déclaration de la méthode avant de choisir le palier.
Chacune des 21 entrées deploy_ porte son propre contrat dans config.json : les champs typés qu'elle accepte, si elle prend un release_doc_id, les étapes de tâche qu'elle va parcourir et leur délai d'expiration, l'habilitation qu'elle exige, et le plancher min_plan qui la sous-tend. Cette entrée est le contrat, pas l'assistant guidé dessiné par-dessus. Déterminez le scénario que vous déployez réellement, lisez cette seule entrée, puis achetez le palier que son min_plan désigne. Six des 21 ne nomment aucun plan, une nomme free, douze nomment pro, deux nomment agency, et aucun déploiement, où que ce soit, ne nomme team.