21 métodos de despliegue, y 10 de ellos llevan su código.
Un escenario de uso en esta plataforma no es una categoría de marketing, es el nombre de un método. config.json declara exactamente 21 métodos cuyo nombre empieza por deploy_, config_dev.json declara los mismos 21, y cada forma de despliegue que ofrece Xuda es una de esas entradas. Diez de ellas publican una compilación de su proyecto, y un solo campo le dice cuáles son esas diez: son las entradas que reciben data.release_doc_id. Las otras once aprovisionan infraestructura o escriben un registro. Esas mismas diez establecen req.data.deploy_type y delegan en una única función compartida, deploy_app, que a su vez no está declarada en cpi_methods, así que no existe una llamada de despliegue genérica. Usted elige una puerta de entrada por su nombre, y el código compartido que hay detrás lee el tipo de la solicitud. El mínimo de plan está escrito en cada entrada y no en una página de precios: deploy_mini_app es el único método de todo el catálogo de 1010 entradas con min_plan free, doce métodos deploy_ llevan min_plan pro, dos llevan agency, y seis no llevan min_plan en absoluto, lo que significa que todo el mundo pasa esa puerta. Contando solo la puerta del plan, 7 de los 21 son accesibles en Free, 19 en Pro, 19 en Team y 21 en Agency, frente a precios de membresía de 0, 49, 149 y 399 dólares al mes. Esta página recorre los ocho patrones con los que la gente llega de verdad, nombra el método al que se resuelve cada uno y nombra los que no se resuelven a nada.
El escenario con el que llegó y el método al que se resuelve.
La gente no llega pidiendo deploy_spa. Llega con una forma en mente: una aplicación para clientes, un sitio sin código detrás, una tarea que se ejecuta a las tres de la madrugada, una copia contra la que probar. Cada una de esas se resuelve en una o dos entradas con nombre en cpi_methods, y la resolución queda fijada en el momento de la llamada en lugar de elegirse en tiempo de ejecución. Lea cada fila como una alternativa y las etiquetas que la acompañan como las llamadas que realmente le cuesta.
Métodos cuyo nombre empieza por deploy_
De esos, accesibles con una cuenta Free
Métodos del catálogo restringidos a Pro que son despliegues
Métodos de despliegue restringidos a Team
Qué le pide una llamada de despliegue y qué hace con la respuesta.
Las 21 entradas no comparten una firma, pero cuatro campos de la declaración le dicen casi todo sobre una de ellas antes de abrir su manejador: si recibe un id de release, si recibe una región, si se ejecuta como un job con seguimiento y qué script ejecuta ese job. Otros dos deciden quién puede llamarla siquiera. 14 de las 21 requieren clearance admin y 7 requieren clearance user, y 20 de las 21 llevan private: true, el indicador que ninguna clave de API externa atraviesa en ningún modo. Desplegar es una acción de operador ejecutada desde una sesión iniciada, no algo que dispara una integración.
- Un id de release, o nada. 10 de las 21 reciben data.release_doc_id, y son exactamente las diez que publican una compilación de su proyecto. Seis de ellas se vinculan a un programa de Studio mediante un data.prog_id obligatorio: embed, mini_app, preview, pwa, spa y user_group. deploy_mpa recibe data.route_id en su lugar. Los otros once métodos aprovisionan infraestructura o escriben un registro y nunca tocan una compilación.
- Una región, normalmente. 16 de las 21 aceptan una región. Las cinco que no lo hacen son instance, marketplace, mini_app, site y static_website. Dos de ellas escriben un documento en xuda_master y no aprovisionan ningún servidor, dos publican archivos en almacenamiento, y la quinta es el despliegue gratuito, que no acepta ninguna región ni ningún campo create_datacenter.
- Un job, normalmente. 14 de las 21 se ejecutan como un job con seguimiento y un job_timeout de 1800000 ms, es decir, 30 minutos, e informan del progreso a través de sus job_steps declarados. Los otros siete devuelven sin job: another, datacenter, instance, marketplace, site, static_website y xucode. Una llamada que responde de inmediato está haciendo papeleo, no aprovisionando.
- Un script, nueve veces. api, cron, embed, emitter, mpa, preview, pwa, spa y user_group ejecutan un script idéntico de 12 pasos con el nombre del tipo sustituido: iniciando el proceso, después crear, firewall, plan de copias de seguridad, conectar e instalar para el servidor del datacenter, luego esos mismos cinco para el servidor del despliegue, y por último activar el servidor. Una sola llamada crea por tanto dos servidores, no uno, salvo que pase data.app_datacenter para reutilizar un datacenter que ya tenga. Ese campo es opcional, igual que los campos create_datacenter que lo acompañan.
Cuatro precios, y solo dos de ellos cambian lo que puede desplegar.
La puerta del plan son cuatro líneas de aritmética. isValidPlan, en cpi/http_module/index.mjs líneas 542 a 547, lee min_plan de la entrada de configuración, devuelve true cuando la clave no está y, en caso contrario, compara dos rangos en PLAN_OBJ: free 0, pro 1, team 2, agency 3. Aplicado a los 21 métodos deploy_*, esa es toda la tabla. El catálogo tiene 19 métodos restringidos a Pro y 12 de ellos son deploy_*, así que una membresía Pro se gasta en su mayor parte justo aquí. Y exactamente un método de las 1010 entradas lleva min_plan free, deploy_mini_app, el único despliegue que puede iniciar una cuenta gratuita. Los precios son mensuales.
Free, $0 | Pro, $49 | Team, $149 | Agency, $399 | |
|---|---|---|---|---|
| Métodos deploy_* que pasan la puerta del plan | 7 de 21 | 19 de 21 | 19 de 21 | 21 de 21 |
| Qué añade este nivel sobre el anterior | los 6 métodos que no declaran ningún min_plan, más deploy_mini_app | 12: another, api, cron, datacenter, embed, emitter, load_balancer, mpa, preview, pwa, spa, user_group | nada. Ni un solo método deploy_* lleva min_plan team | dos: deploy_instance y deploy_marketplace, y ambos escriben un documento en xuda_master sin aprovisionar ningún servidor |
| Despliegues que llevan una compilación de su proyecto, los que reciben data.release_doc_id | 1 de 10, deploy_mini_app | 10 de 10 | 10 de 10 | 10 de 10 |
| Un enlace que usted reparte: spa, pwa, embed, preview | no, los cuatro son pro | sí, un job de 12 pasos cada uno | los mismos 4 que en Pro | los mismos 4 que en Pro |
| Un VPS, un servidor web o un VPS full stack con la CLI de xuda instalada | sí, los tres no declaran min_plan | sí | sí | sí |
| haproxy delante de sus despliegues del mismo tipo | no | deploy_load_balancer, 6 pasos | sí | sí |
| Un segundo entorno de una aplicación que ya tiene en marcha | no | deploy_another, nombre, región y tipo de servidor nuevos | sí | sí |
Una llamada de despliegue, tres destinos, y el primero construye dos servidores.
Diez de los 21 métodos despliegan una compilación de su proyecto. Son los que reciben data.release_doc_id, cada uno establece req.data.deploy_type, y todos delegan en una única función compartida, deploy_app, en cpi/deploy_module/index.mjs línea 116. deploy_app no está declarada en cpi_methods, así que no hay ninguna llamada de despliegue genérica: usted elige una puerta de entrada y la puerta de entrada nombra el tipo. Los otros 11 aprovisionan una máquina o escriben un registro. Lea la primera rama dos veces, porque una sola llamada a deploy_spa aprovisiona un servidor de datacenter antes de aprovisionar el suyo.
Tres pasos, y el del medio es una barra de progreso que usted observa.
No es un asistente. Lo que la entrada de configuración le obliga a aportar, lo que el job informa de vuelta y lo que tiene en sus manos cuando la última línea dice activando el servidor.
- 01
Elija la puerta de entrada, el release y el programa
No hay ninguna llamada de despliegue genérica. deploy_app la comparten los 10 métodos con release pero no está declarada en cpi_methods, así que usted llama a deploy_spa, deploy_pwa, deploy_embed, deploy_preview y demás, y esa elección establece deploy_type por usted. Cada uno de los 10 recibe data.release_doc_id, la compilación que se publica. Seis de ellos, embed, mini_app, preview, pwa, spa y user_group, reciben además un data.prog_id obligatorio que nombra el único programa de Studio al que se vincula el despliegue, y deploy_mpa recibe data.route_id en su lugar. La región es un campo en 16 de los 21.
- 02
Observe cómo se ejecuta el script declarado
job_steps no es una máquina de estados interna, es el texto literal del progreso. 14 de los 21 registran un job con seguimiento y job_timeout de 1800000 ms, un techo de 30 minutos. Un despliegue de enlace informa de 12 líneas, deploy_mini_app 11, deploy_full_stack_vps 8, deploy_vps y deploy_webserver 7 cada uno, deploy_load_balancer 6. Los otros 7 no declaran pasos y responden sin job: another, datacenter, instance, marketplace, site, static_website y xucode.
- 03
Quédese con el servidor activado
El último paso de todo script de aprovisionamiento es activar el servidor, y lo que usted tiene después es una máquina con la región, el firewall y el plan de copias de seguridad que ese mismo script configuró. A partir de ahí, deploy_load_balancer pone haproxy delante de varios despliegues del mismo tipo con comprobaciones de salud y conmutación por error, y deploy_another vuelve a desplegar toda la aplicación con un nombre, una región y un tipo de servidor nuevos, propagándose a sus despliegues hijos. Ambos son min_plan pro.
Doce líneas, y seis de ellas son una máquina que usted nunca nombró.
El arreglo job_steps de deploy_spa en orden, exactamente como lo declara config.json y como lo lee de vuelta la barra de progreso. Las mismas 12 líneas, con el nombre del tipo sustituido, están declaradas en deploy_api, deploy_cron, deploy_embed, deploy_emitter, deploy_mpa, deploy_preview, deploy_pwa y deploy_user_group. Lea primero las líneas 02 a 06: son un servidor de datacenter.
Ocho límites, tres de ellos métodos que están declarados y aun así se niegan a ejecutarse.
- Router no despliega. deploy_mpa está declarado, restringido al plan pro, y establece req.data.deploy_type como mpa, un valor ausente del arreglo deploy_type de config.json, así que deploy_app lo rechaza con el código -2 en cpi/deploy_module/index.mjs líneas 139 a 141. config_dev.json sí lista mpa, y además lo lista como beta, así que ahí se rechaza cuatro líneas más adelante. Un despliegue de router multipágina no es algo que se pueda iniciar hoy.
- Emitter está en beta en la configuración que se distribuye. La cadena emitter está en deploy_type_in_beta en config.json, así que deploy_app devuelve el código -2 en cpi/deploy_module/index.mjs líneas 143 a 144. config_dev.json la ha quitado de esa lista, lo que significa que el patrón de feed de cambios funciona en dev y se rechaza en la copia del repositorio. El método está declarado y la tubería de aprovisionamiento que hay detrás es la misma que usa cron. La barrera es una sola entrada de un arreglo.
- Ningún método compila un binario de iOS, Android o macOS. deploy_ios, deploy_android y deploy_macos existen en cpi/deploy_module/index.mjs, líneas 1388 a 1405, y ninguno de los tres está declarado en cpi_methods, así que nada que llegue por /cpi puede alcanzarlos. El antiguo patrón de aplicación móvil está descartado, no aplazado.
- No existe un tipo de despliegue de colaboración en tiempo real. Ninguno de los 21 aprovisiona un websocket, un canal de presencia ni una superficie CRDT. Lo más parecido del conjunto, deploy_emitter, es trabajo por lotes del lado del servidor disparado por un feed de cambios de la base de datos, y de todos modos se rechaza por estar en beta.
- MCP Server figura como tipo de despliegue en ambas configuraciones, está en deploy_type_in_beta en las dos y no tiene ninguna entrada deploy_mcp en cpi_methods, así que no hay nada a lo que llamar ni siquiera antes de la barrera de beta. Un despliegue de MCP por proyecto no existe.
- Team cuesta 149 dólares frente a los 49 de Pro y no compra nada en esta página. Cero métodos deploy_ llevan min_plan team, así que Pro y Team llegan ambos a 19 de los 21. Agency, a 399 dólares, añade exactamente dos más, deploy_instance y deploy_marketplace, y ambos crean un documento en xuda_master y no aprovisionan ningún servidor.
- deploy_xucode es la única entrada deploy_ sin clave microservice, y http_module retorna de inmediato cuando falta microservice en cpi/http_module/index.mjs líneas 942 a 944, así que la llamada nunca llega a su manejador en cpi/deploy_module/index.mjs línea 1777. Es además el único de los 21 que omite private.
- Un despliegue de sitio web estático no ejecuta código. deploy_static_website lee una carpeta de Drive y se la entrega a deploy_site, que sube los archivos a R2 y cambia un puntero KV de forma atómica. Sin servidor, sin cron, sin API, sin base de datos. Un manejador de formularios o una tarea programada es un segundo despliegue en un segundo servidor.
Qué se puede desplegar realmente hoy
Seis respuestas leídas de config.json y de cpi/deploy_module/index.mjs, no del asistente que se dibuja encima de ellos.
Vea cómo sale un despliegue.
Doce pasos, dos servidores y un id de job con un tiempo de espera de 30 minutos. El mismo script que ejecutan nueve de los 21 métodos, con el nombre del tipo sustituido.
Lea la declaración del método antes de elegir el nivel.
Cada una de las 21 entradas deploy_ lleva su propio contrato en config.json: los campos tipados que acepta, si recibe un release_doc_id, los pasos de job que recorrerá y el tiempo de espera sobre ellos, la autorización que exige y el mínimo de min_plan que hay debajo. Esa entrada es el acuerdo, no el asistente dibujado encima. Averigüe qué forma está desplegando en realidad, lea esa única entrada y después compre el nivel que nombra su min_plan. Seis de los 21 no nombran ningún plan, uno nombra free, doce nombran pro, dos nombran agency, y ningún despliegue nombra team.