¿Cuál es la diferencia entre CI y CD?

CI (integración continua) fusiona cambios con frecuencia y ejecuta build y pruebas en cada uno. CD (entrega o despliegue continuo) toma un cambio que pasó CI y lo deja listo para publicar o lo publica directamente en producción.

¿Necesito CI/CD en un proyecto pequeño?

Al principio no. Para un bot o un sitio personal, desplegar a mano está bien. CI/CD compensa cuando hay pruebas que ejecutar, varias personas en el código o deploys tan frecuentes que los pasos manuales empiezan a causar errores.

¿GitHub Actions es una herramienta de CI/CD?

Sí. GitHub Actions ejecuta workflows definidos en archivos YAML de tu repositorio, disparados por eventos como un push, y esos workflows pueden compilar, probar y desplegar código.

Qué es CI/CD y cómo funciona un pipeline

Q: ¿Cuál es la diferencia entre entrega continua y despliegue continuo?

En la entrega continua, todo cambio que pasa las pruebas queda listo para publicar, pero una persona aprueba el último paso. En el despliegue continuo, la publicación es automática y sin aprobación.

Sin automatización, desplegar código se ve así: terminas un cambio, te acuerdas de ejecutar las pruebas (o no), comprimes el proyecto, lo subes y reinicias la app. Cada paso es una oportunidad de olvidar algo, y la persona que conoce la rutina se convierte en un cuello de botella.

CI/CD sustituye esa rutina por un script que se ejecuta igual en cada cambio. Es una práctica habitual en equipos de software y funciona bien incluso para una sola persona con un bot o una API.

¿Qué significa CI/CD?#

CI/CD une dos ideas que a menudo se confunden:

CI, integración continua: los desarrolladores fusionan sus cambios con frecuencia en una rama compartida, y cada fusión dispara un build y una ejecución de pruebas automáticos. El objetivo es detectar un cambio roto minutos después de escribirlo, no semanas después.
CD, entrega continua o despliegue continuo: la parte posterior a CI. El cambio que pasó se empaqueta y sigue hacia producción.

En la "D" empieza la confusión, porque significa dos cosas distintas.

¿Cuál es la diferencia entre entrega continua y despliegue continuo?#

Ambas automatizan todo hasta la publicación. Se diferencian en el último paso:

	Entrega continua	Despliegue continuo
Build y pruebas	Automáticos	Automáticos
Publicación en producción	Una persona la aprueba	Automática, sin aprobación
Uso típico	Equipos que quieren un control humano (horario laboral, visto bueno)	Equipos con buenas pruebas y cambios pequeños y frecuentes

El despliegue continuo no es "mejor". Exige pruebas en las que confíes, porque nadie detiene un cambio malo al final. Muchos equipos empiezan con entrega continua y aprobación manual, y quitan la aprobación cuando las pruebas se ganan esa confianza.

¿Cómo funciona un pipeline de CI/CD?#

Un pipeline es la secuencia de etapas automáticas que recorre un cambio. Uno típico funciona así:

Disparador. Un evento inicia la ejecución: un push a una rama, un pull request, una release publicada, una programación o un clic manual.
Checkout. Una máquina limpia recibe una copia del código en ese commit.
Build. Se instalan las dependencias y se compila o empaqueta el proyecto.
Pruebas. Se ejecutan pruebas unitarias y, a veces, linters, verificación de tipos y pruebas de integración. Si algo falla, el pipeline se detiene aquí.
Publicación. El resultado se envía a producción, o antes a un entorno de staging.
Verificación. Una prueba de humo o un health check confirma que la nueva versión está viva.

Lo central es que un fallo detiene el flujo: prueba rota, no hay deploy.

¿Cómo se ve un pipeline de CI/CD en la práctica?#

En GitHub, un workflow es un archivo YAML guardado en .github/workflows/ de tu repositorio. Un evento, como un push, inicia el workflow. Este contiene uno o más jobs, y cada job se ejecuta en un runner, el servidor que ejecuta sus pasos. Los jobs se ejecutan en paralelo por defecto, y needs hace que uno espere a otro.

Este workflow es la parte de CI de un proyecto Node.js: ejecuta las pruebas en cada push a main y en cada pull request.

yaml

name: CI

on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: lts/*
      - run: npm ci
      - run: npm test

actions/checkout@v7 copia tu código al runner (revisa la versión mayor actual en la página de releases de la acción), y lts/* instala la versión LTS activa de Node.js. npm ci instala exactamente lo que dice el lockfile, lo que mantiene CI reproducible. Para convertirlo en CD, añades un segundo job con needs: test que envía el código al servidor. La versión completa, con secrets y paso de deploy, está en deploy automático con GitHub Actions.

GitLab CI, CircleCI y Jenkins hacen lo mismo con otra sintaxis, y los conceptos anteriores se aplican igual.

¿Por qué los equipos usan CI/CD?#

Menos publicaciones rotas. Las pruebas corren en cada cambio, incluso en los que estabas seguro de que eran inofensivos.
Cambios más pequeños y seguros. Si desplegar es barato, publicas piezas pequeñas. Un cambio pequeño es más fácil de revisar y de deshacer.
Repetibilidad. El pipeline hace los mismos pasos en el mismo orden. "En mi máquina funciona" importa menos cuando un runner limpio lo construye.
El conocimiento no depende de una persona. El procedimiento de deploy vive en un archivo del repositorio, no en la cabeza de alguien.
Respuesta más rápida. Te enteras de un build fallido cuando el cambio aún está fresco en tu mente.

¿Cuándo no vale la pena usar CI/CD?#

El pipeline también tiene un costo. Es código que debes mantener, secrets que debes proteger y una fuente propia de fallos (una prueba inestable bloquea a todos).

Un bot personal sin pruebas gana poco con CI. Un deploy manual toma un minuto.
Sin pruebas, CI solo demuestra que el código compila. Desplegar automáticamente sin pruebas solo publica los errores más rápido.
Un pipeline lento se ignora. Si las pruebas tardan 40 minutos, la gente deja de esperarlas.

Un camino razonable: empieza ejecutando pruebas en los pull requests (solo CI), luego añade un deploy automático a un entorno de staging y solo después automatiza el deploy a producción.

¿Cómo se hace rollback cuando un deploy sale mal?#

CI/CD lleva el código a producción rápido, así que necesitas una vuelta atrás igual de rápida. Lo más simple es volver a desplegar el último commit bueno. Si la app tiene datos, guarda también copias de ellos: el código se puede revertir, una base de datos corrupta no. Mira rollback y deploys sin downtime para conocer las opciones.

Cómo hacerlo en Square Cloud#

Square Cloud es hospedaje self-service, así que tú controlas el pipeline: tu CI decide cuándo algo está listo y el paso de deploy lo envía. Puedes desplegar desde GitHub con la GitHub Action oficial o llamar a la CLI de código abierto desde cualquier sistema de CI. Ahí se autentica con la variable SQUARECLOUD_API_KEY, sin iniciar sesión en el navegador.

La GitHub Action oficial, squarecloudofc/github-action@v2, ejecuta el comando de la CLI de su entrada command, por ejemplo commit <appId> --restart, en cada push, release o ejecución manual. Solo necesita una API key, guardada como secret en tu repositorio y pasada en la entrada token. Pon tus pruebas en un job anterior y usa needs: si una prueba falla, el deploy no ocurre.

Las variables de entorno se definen por aplicación en el panel, la API, la CLI o VS Code, y el cambio se aplica en el siguiente reinicio sin rebuild, así que no hace falta ponerlas en el pipeline. El archivo de configuración squarecloud.app es opcional: el panel lo genera al desplegar, o puedes escribirlo en la raíz del proyecto.

Consulta la página de la GitHub Action para la configuración.

Qué es CI/CD