OneDev en VPS: Git, CI/CD y Kanban autoalojados

Gitea es excelente para alojar código: es ligero, rápido y cubre todas las necesidades de una forja Git clásica. Pero en cuanto se quiere CI/CD, hay que instalar un runner aparte (gitea/act_runner), configurarlo, vigilar sus jobs y exponerlo a la red. OneDev hace todo eso por defecto: cuando usted envía un .onedev-buildspec.yml, un pipeline se pone en cola y se ejecuta en un contenedor Docker en el mismo VPS — ningún servicio adicional que configurar.

Esta integración se extiende a las issues y a los tableros Kanban: en lugar de gestionar un proyecto en una tercera aplicación, las tarjetas Kanban de OneDev se mueven automáticamente cuando se crea una rama, se abre una pull request o se fusiona un commit. El resultado es un puesto de desarrollo coherente, sin malabares entre pestañas.

OneDev funciona como dos contenedores Docker: 1dev/server (la aplicación Java) y postgres:14 (la base de datos). La aplicación escucha en el puerto 6610; ServOrbit coloca un vhost nginx delante de ella y gestiona el TLS. Todo pasa por el mismo dominio: la interfaz web, los clones Git por HTTPS, los webhooks de CI y el registro de paquetes.

La imagen 1dev/server incluye además un agente de build local. Cuando arranca un pipeline, lanza un contenedor Docker para cada etapa de build — por eso el socket Docker (/var/run/docker.sock) se monta en el contenedor OneDev. Este diseño es estándar en las plataformas de CI autoalojadas (Jenkins, Drone, Woodpecker también lo usan) y permite configurar runners remotos si necesita paralelismo o aislamiento de hardware.

La base de datos PostgreSQL almacena los repositorios (en forma de repositorios Git bare en /opt/onedev), las issues, los miembros, los jobs de CI y la configuración. Un solo volumen Docker basta para respaldarlo todo.

La RAM consumida al arrancar es de unos 512 MB en un VPS sin usuarios activos. La JVM HotSpot optimiza la memoria con las sucesivas ejecuciones, pero conviene empezar con 2 GB para dejar margen a los builds Docker concurrentes. Un VPS de 4 GB de RAM es suficiente para un equipo de diez desarrolladores con dos o tres jobs de CI en paralelo.

OneDev usa su propio formato YAML de pipeline, distinto del de GitHub Actions o GitLab CI. La estructura básica se compone de jobs con steps. Cada step puede usar una imagen Docker, ejecutar un script, publicar un artefacto o enviar una notificación.

Ejemplo mínimo para un proyecto Node.js:

version: 36
jobs:
- name: Build
  steps:
  - !CheckoutStep
    name: checkout
    cloneCredential: !DefaultCredential {}
  - !CommandStep
    name: install and test
    image: node:20-alpine
    commands:
    - npm ci
    - npm test
  triggers:
  - !BranchUpdateTrigger {}

El diseñador visual de pipelines genera ese YAML de forma gráfica: usted añade etapas desde la interfaz, configura las imágenes Docker, las variables de entorno y los disparadores, y OneDev escribe el archivo por usted. Resulta útil para empezar, aunque la mayoría de los equipos acaba editando el YAML directamente para lograr un control más fino.

Los !CommandStep admiten matrices de build (matrix), los artifacts entre etapas (artifactRequirements) y las condiciones de disparo (branchUpdateTrigger, pullRequestTrigger, tagCreateTrigger). Los pipelines también pueden programarse mediante scheduleTrigger para tareas nocturnas — migraciones de base de datos, generación de informes, limpieza de ramas. Un panel dedicado muestra el estado de todos los jobs en tiempo real y conserva el historial completo de las ejecuciones con los logs con marca de tiempo.

OneDev almacena todo en dos volúmenes Docker: onedev_data (repositorios Git, configuración, jobs) y onedev_db (base de datos PostgreSQL). Una copia de seguridad completa consiste en archivar esos dos volúmenes.

docker run --rm \
  -v onedev_data:/data \
  -v /backup:/backup \
  alpine tar czf /backup/onedev-data.tar.gz /data

docker run --rm \
  -v onedev_db:/pgdata \
  -v /backup:/backup \
  alpine tar czf /backup/onedev-db.tar.gz /pgdata

Como alternativa, el comando pg_dump desde el interior del contenedor PostgreSQL produce un volcado SQL más portable. Los repositorios Git de onedev_data son repositorios bare estándar: un git clone --mirror hacia un almacenamiento externo es otra estrategia válida para los repositorios por sí solos.

OneDev también puede configurar copias de seguridad automáticas hacia un almacenamiento de objetos compatible con S3 desde Site Administration → Settings → Backup Settings. El volumen onedev_data contiene a la vez los repositorios Git y los archivos de configuración de OneDev — por eso es más voluminoso que el volumen de una simple base SQL. Calcule 1 GB por repositorio activo para la ventana de retención de builds de CI (logs, artefactos) y prevea un almacenamiento de objetos si acumula muchos artefactos de build.