Añade a esta persona a Vercel para que pueda desplegar. O simplemente no lo hagas.

En el momento de esta implementación, Vercel Pro costaba $20 por puesto. Tres ingenieros costaban $60 al mes y cinco o seis costaban entre $100 y $120. El equipo conservó un solo puesto de proyecto de $20 y trasladó la ejecución del despliegue a GitHub Actions mediante Vercel CLI.

El repositorio guardaba VERCEL_TOKEN, VERCEL_ORG_ID y VERCEL_PROJECT_ID como secretos. Los ingenieros podían entregar trabajo revisado mediante la ruta normal de fusión basada en trunk sin recibir credenciales individuales para el panel.

Dividí el despliegue en dos flujos de trabajo. Las fusiones a main actualizaban preproducción; el paso a producción exigía un lanzamiento manual después de QA, activado por un usuario autorizado de GitHub.

Solicitud de cambios -> revisión -> fusión en main
  -> compilación y despliegue automáticos en preproducción
  -> QA
  -> flujo autorizado de producción
  -> etiqueta, publicación, despliegue, aviso en Slack

El acceso al repositorio no concedía automáticamente acceso a producción. El flujo original permitía que Elusive7733 activara producción, mientras el resto del equipo entregaba mediante solicitudes de cambios y preproducción.

Cada envío a main extraía la configuración del entorno staging, creaba un artefacto precompilado con --target=staging y desplegaba exactamente esa salida. Un grupo de concurrencia compartido usaba cancel-in-progress: true para que un commit más reciente de main sustituyera un despliegue obsoleto, estuviera en cola o en ejecución.

concurrency:
  group: staging-deploy
  cancel-in-progress: true

- run: vercel pull --yes --environment=staging --token=$VERCEL_TOKEN
- run: vercel build --target=staging --token=$VERCEL_TOKEN
- run: vercel deploy --prebuilt --target=staging --token=$VERCEL_TOKEN

El flujo manual de producción aceptaba patch, minor o major. Con todo el historial de Git disponible, leía la etiqueta más reciente, calculaba la siguiente versión semántica, creaba y enviaba la etiqueta, extraía el entorno de producción, creaba el artefacto precompilado y lo desplegaba.

Una ruta skip-tagging independiente reutilizaba la versión más reciente para volver a desplegarla. La recuperación no necesitaba crear un número de versión nuevo y falso solo para volver a ejecutar la infraestructura.

on:
  workflow_dispatch:
    inputs:
      version_type:
        type: choice
        options: [patch, minor, major]
      skip_tagging:
        type: boolean
        default: false

Después de una versión etiquetada, gh release create --generate-notes generaba el registro de cambios. .github/release.yml agrupaba las solicitudes de cambios por etiqueta. El flujo añadía metadatos del despliegue y enviaba un aviso de versión con formato mediante un webhook de Slack.

Primero construí un generador de registros de cambios con IA y lo eliminé tres días después. GitHub ya enumeraba cada solicitud fusionada y su enlace, así que el modelo añadía código sin aportar información útil sobre la versión.

La secuencia de trabajo era sencilla: fusionar una solicitud revisada, desplegarla en preproducción, verificarla y permitir que un usuario autorizado activara producción. Las etiquetas de versión, las publicaciones de GitHub y los mensajes de Slack dejaban un registro fuera del panel de Vercel.

• Usa la protección del repositorio y del entorno para las credenciales que sustituyen el acceso al panel.
• Separa los despliegues automáticos de revisión de una ejecución deliberada en producción.
• Compila una vez y despliega el artefacto precompilado en cada entorno.
• Usa las notas nativas de la versión como opción predeterminada antes de añadir otro sistema de generación.