Proyectos y entornos

Un proyecto es un lienzo de servicios que van juntos. Cada proyecto tiene un entorno de producción y tantos otros como necesites, incluido uno por cada pull request.

El modelo de objetos es el mismo que el de Railway:

espacio de trabajo   facturación, miembros, tokens de API
└── proyecto         un lienzo: servicios, bases de datos, volúmenes, dominios
    └── entorno      production, staging, pr-42 …
        └── servicio un repositorio o una imagen
            └── despliegue

Espacios de trabajo#

Iniciar sesión con GitHub crea un espacio de trabajo personal con un pequeño crédito de prueba. Los espacios de trabajo son dueños del saldo y del plan (Facturación), de los miembros y sus roles (owner, admin, member) y de los tokens de API. Crea más espacios de trabajo desde el selector de espacios de trabajo o con workspaceCreate; esos no reciben el crédito de prueba.

Proyectos#

Un proyecto agrupa los servicios de una aplicación. Todo lo que está dentro de un proyecto comparte una red privada por entorno y puede referenciar las variables de los demás.

Nuevo proyecto en la página de proyectos. Elige un repositorio para crear el primer servicio de inmediato, o empieza vacío y agrega servicios en el lienzo.

La configuración del proyecto guarda el nombre, la descripción, la instalación de la GitHub App que se usa para los repositorios privados y el interruptor de despliegues de PR (ver abajo). Eliminar un proyecto elimina sus servicios, volúmenes y entornos.

Entornos#

Cada proyecto empieza con production. Un entorno es una copia completa del grafo de servicios: los mismos servicios con su propia configuración, variables, dominios, volúmenes y despliegues. Un servicio se crea a nivel de proyecto; su configuración por entorno (ServiceInstance) se crea con valores predeterminados la primera vez que la tocas.

skiffly environment                        # cambia el entorno vinculado
skiffly environment list
skiffly environment new staging --duplicate production

--duplicate copia las variables y la configuración de los servicios desde el entorno de origen. En GraphQL es environmentCreate(input: { projectId, name, sourceEnvironmentId }).

Rama distinta por entorno: un servicio sigue una sola rama de forma predeterminada; con serviceInstanceUpdate(input: { branch }) (o branch en configuración como código) puedes apuntar staging a develop mientras production se queda en main.

Entornos de vista previa por pull request#

Activa las vistas previas de PR en la configuración del proyecto (projectUpdate(id, input: { prDeploys: true })). Después, por cada pull request abierto contra un repositorio conectado:

Se crea un entorno llamado pr-<número> como copia de production.
Los servicios construidos desde ese repositorio siguen la rama del PR; los demás servicios (bases de datos, workers de otros repositorios) se despliegan igual que en producción.
Cada push al PR vuelve a desplegar solo los servicios de ese repositorio.
Cerrar o fusionar el PR elimina el entorno, volúmenes incluidos.

Los pull requests desde forks se ignoran: ejecutarían el código de otra persona con tus secretos.

Miembros y roles#

Invita a personas desde Personas en la barra lateral del espacio de trabajo (workspaceInvite). Roles: owner (todo, incluido eliminar el espacio de trabajo), admin (facturación, tokens, miembros), member (proyectos, servicios, despliegues, logs, shell). El acceso es por espacio de trabajo; todavía no hay permisos por proyecto.

Registro de auditoría#

Cada mutación que cambia algo se escribe en el registro de auditoría del espacio de trabajo (auditLog(workspaceId)): despliegues, cambios de variables, cambios de dominios, sesiones de shell, eventos de facturación. El panel lo muestra en Configuración → Registro de auditoría.