Desarrollo seguro: Parte 1 — CI/CD: de despliegue manual a despliegue automático

CI/CD — es una práctica en la que cada cambio de código se compila, verifica y entrega al servidor de forma automática. En lugar de la secuencia manual «copiar archivos, reiniciar el servicio y comprobar que no se rompió nada», este trabajo lo hace un programa según una descripción que se guarda en el repositorio junto al código.

Con esto se abre el ciclo de desarrollo seguro. Todas las comprobaciones siguientes — búsqueda de secretos, análisis estático de código, verificación de dependencias y de imágenes de contenedores — se integran en el pipeline, por eso hay que empezar por él.

CI, CD y otra vez CD

• Integración continua (Continuous Integration). Tras cada git push el código se construye y pasa tests. Un error se detecta en minutos tras el commit, no el día del despliegue.
• Entrega continua (Continuous Delivery). Cada build exitosa está lista para desplegarse, pero la orden de despliegue la da una persona.
• Despliegue continuo (Continuous Deployment). El build exitoso se envía al servidor automáticamente, sin intervención humana.

A los equipos pequeños suele convenir el segundo modelo: todo se comprueba automáticamente y el despliegue se lanza con un botón.

De qué consta el pipeline

• Archivo de descripción en el repositorio: .gitlab-ci.yml, .github/workflows/*.yml, .gitea/workflows/*.yaml o Jenkinsfile.
• Etapas y tareas. Las etapas se ejecutan en orden; las tareas de una etapa, en paralelo si hay suficientes ejecutores.
• Runner — programa que ejecuta las tareas. En GitLab.com y GitHub.com hay runners en la nube; en un servidor propio de GitLab o Gitea hay que instalar y registrar el runner manualmente.
• Variables y secretos se definen en la configuración del proyecto, no en el archivo del pipeline.

Herramientas

GitLab CI está integrado en GitLab — tanto en el GitLab.com en la nube como en la instalación en servidor propio. El pipeline se describe en el archivo .gitlab-ci.yml en la raíz del repositorio. En tu servidor GitLab las tareas empezarán a ejecutarse solo tras instalar y registrar GitLab Runner.

GitHub Actions está integrado en GitHub. Los archivos de pipeline se colocan en el directorio .github/workflows; para pasos típicos hay una gran librería de acciones listas para usar.

Gitea Actions aparecieron en Gitea 1.19 y desde la versión 1.21 están habilitadas por defecto. La sintaxis es en gran medida compatible con GitHub Actions, los archivos se colocan en .gitea/workflows/ y las tareas las ejecuta un programa separado, Gitea Runner. Es una opción ligera para una empresa que necesita un servidor Git propio con automatización integrada.

Jenkins es un servidor de automatización independiente: los pipelines se describen en Jenkinsfile y sus capacidades se amplían con plugins. Es muy flexible, pero el mantenimiento, las actualizaciones y la compatibilidad de plugins corren por tu cuenta. Normalmente se elige donde ya lleva tiempo funcionando.

Pipeline mínimo funcional

Ejemplo para GitLab CI: tests en cada cambio y despliegue solo desde la rama principal.

stages:
  - test
  - deploy

test:
  stage: test
  image: python:3.13-slim
  script:
    - pip install -r requirements.txt
    - pytest

deploy:
  stage: deploy
  script:
    - ./deploy.sh
  environment: production
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      when: manual

La tarea deploy aparece solo en la rama principal y espera lanzamiento manual — esto es entrega continua. Si se quita when: manual, se obtiene despliegue continuo.

Lo mismo para GitHub Actions — archivo .github/workflows/ci.yml:

name: CI

on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    container: python:3.13-slim
    steps:
      - uses: actions/checkout@v6
      - run: pip install -r requirements.txt
      - run: pytest

Para Gitea Actions vale un archivo casi igual, solo que en el directorio .gitea/workflows/.

Dónde en el pipeline van las comprobaciones de seguridad

La comprobación aporta valor solo si puede detener el pipeline: las advertencias que no afectan a nada dejan de leerse. Un orden razonable es activar la comprobación en modo informe, analizar lo encontrado y luego hacerla obligatoria.

Secretos y accesos del pipeline

• Contraseñas y claves se almacenan en variables protegidas del proyecto (en GitLab — masked y protected, en GitHub — secrets), no en el archivo YAML.
• Para el despliegue se crea un usuario y una clave separados con permisos mínimos — solo lo necesario para el despliegue.
• El despliegue solo se permite desde la rama principal.
• Un runner en un servidor propio no debe ejecutar tareas de proyectos ajenos: la documentación de Gitea advierte directamente que no se deben usar runners no confiables ni proporcionar tus runners a instancias no confiables.

Para más detalles sobre la protección de secretos en GitLab CI, GitHub Actions y Gitea Actions, consulta Secretos y zero trust: Parte 7 — Secretos en CI/CD: GitLab, GitHub Actions y Gitea Actions.

GitOps

Para Kubernetes es común el enfoque GitOps: el estado deseado del clúster está descrito en Git y un agente especial en el clúster (Argo CD o Flux) hace que el clúster se ajuste a esa descripción. En ese caso el pipeline no despliega la aplicación directamente, solo actualiza los manifiestos en el repositorio. Para uno o dos servidores sin Kubernetes es una complejidad excesiva — basta un paso de despliegue normal.

Qué tener en cuenta en Rusia

• No se puede pagar las tarifas internacionales de GitHub y GitLab.com con tarjeta de un banco ruso: Visa y Mastercard, desde marzo de 2022, no funcionan fuera de Rusia.
• Independizarse de servicios externos se logra con un servidor Git propio — GitLab en tu servidor o Gitea con Gitea Actions — y runners en tus máquinas. Esa opción requiere administración, pero el código, las compilaciones y los secretos quedan bajo tu control.

Errores típicos

• Contraseñas en el archivo del pipeline. Acaban en el historial de Git y son visibles para cualquiera con acceso al repositorio.
• Comprobaciones que no detienen la build. Sus resultados no los mira nadie.
• Pipeline largo. Si la build dura media hora, los desarrolladores dejan de esperar resultados. Ayudan el caché de dependencias y tareas en paralelo.
• Despliegue desde cualquier rama. Código experimental llega al servidor productivo.
• Un solo runner con acceso a producción para todos los proyectos. Un fallo o una intrusión en un proyecto abre acceso al resto.

La configuración del pipeline para un proyecto concreto — desde los primeros tests hasta el despliegue en tus servidores — forma parte del servicio de configuración de CI/CD.