¿Por qué los desarrolladores están trasladando los ejecutores de CI, los registros y las bases de datos de prueba fuera de sus portátiles?
Los equipos trasladan estos servicios fuera de los portátiles para que las compilaciones sean repetibles, las dependencias compartidas estén disponibles, los datos de prueba sean descartables y la entrega no dependa de la batería ni del espacio de trabajo de un desarrollador.
El servidor no es un portátil más grande. Un ejecutor de CI ejecuta instrucciones de proyectos no confiables, un registro almacena artefactos de la cadena de suministro y una base de datos de pruebas contiene datos mutables. Combinarlos puede ser eficiente para un equipo pequeño, pero solo si las identidades, las redes, el almacenamiento, los secretos, las cuotas y la recuperación se separan según la función.
Empieza por el problema del flujo de trabajo
La CI alojada en un portátil falla cuando su propietario duerme, viaja, cambia de red, cierra la tapa o necesita la CPU y la memoria locales. Un registro local desaparece cuando ese equipo deja de estar disponible, mientras que una base de datos de pruebas acumula un estado que solo entiende un desarrollador.
La integración continua depende de verificaciones automatizadas y frecuentes cuyos resultados estén a la vista de todos. Las prácticas de integración continua de Martin Fowler destacan las compilaciones con pruebas automáticas y resultados visibles: propiedades difíciles de garantizar en un portátil que solo está disponible de forma intermitente.
Traslada un servicio solo después de identificar el problema que resuelve: retrasos en la cola, diferencias entre entornos, distribución de imágenes, estado de integración compartido o falta de recursos en los portátiles.
Separa los límites de confianza de los ejecutores
Trata los trabajos de CI como ejecución de código. Cuando sea práctico, usa contenedores o máquinas virtuales efímeros, evita montar el socket de Docker del host en trabajos no confiables y asigna credenciales de alcance limitado a cada repositorio o canalización.
Asigna cuotas al espacio de trabajo y a las cachés de compilación. Un trabajo fallido no debe llenar el sistema de archivos raíz del servidor ni leer credenciales del registro que no estén relacionadas con su proyecto.
Define las etiquetas de los ejecutores según el nivel de confianza y sus capacidades. No envíes código de solicitudes de incorporación de cambios de colaboradores desconocidos a un ejecutor que pueda acceder a secretos de producción o a la red doméstica.
Convierte el registro en un servicio de distribución duradero
Almacena los datos y la configuración del registro en un almacenamiento persistente con autenticación, TLS en rutas no confiables, reglas de retención y períodos para la recolección de basura. Separa las etiquetas de versiones inmutables de las imágenes descartables de ramas.
Haz copias de seguridad de la configuración, los metadatos y los artefactos que no se puedan reconstruir. Si las imágenes se pueden reproducir a partir del código fuente, documenta el tiempo de reconstrucción y conserva el código fuente, las definiciones de compilación y las dependencias externas, en lugar de hacer copias de seguridad de cada capa de caché.
Supervisa la capacidad antes de limpiar. La recolección de basura del registro puede consumir mucho tiempo de E/S y, según la implementación, requerir un estado de mantenimiento.
Mantén las bases de datos de prueba desechables, pero representativas
Asigna a cada canalización o rama un nombre de base de datos, esquema, contenedor o máquina virtual aislados. Siémbralos con datos de prueba versionados o un conjunto de datos anonimizado, ejecuta las migraciones automáticamente y elimínalos tras el periodo de retención.
Nunca copies secretos de producción ni datos personales sin anonimizar a la función de prueba. Limita el alcance de la red para que una tarea comprometida no pueda pasar de la base de datos de prueba a servicios no relacionados.
Conserva solo los registros y artefactos necesarios para diagnosticar pruebas fallidas. Las bases de datos persistentes de origen desconocido recrean el problema del portátil en una máquina más grande.
Crea la topología de servidor para equipos pequeños
Usa cuentas de servicio, redes de contenedores, volúmenes, cuotas y reglas de copia de seguridad independientes para las funciones de ejecutor, registro y base de datos. Esta guía sobre plataformas NAS y Docker ayuda a decidir si los contenedores o las máquinas virtuales deberían proporcionar el aislamiento.
Coloca la interfaz de administración en una red restringida. Expón el registro y la interfaz de CI solo al equipo o mediante una capa de acceso autenticado. Registra las actualizaciones, la propiedad y el procedimiento de reversión de cada servicio.
Prueba la recreación de un ejecutor, la restauración o reconstrucción del registro, la resiembra de la base de datos, la situación de disco lleno y el reinicio del servidor. Los desarrolladores deberían poder seguir trabajando localmente mientras se recuperan los servicios compartidos.
Comprobación final de la configuración
La migración se completa con éxito cuando las compilaciones se ejecutan sin depender de un portátil concreto, los entornos se recrean a partir de definiciones versionadas, los artefactos del registro cuentan con un plan de retención y recuperación, las bases de datos de prueba están aisladas y se pueden descartar, y ningún ejecutor tiene más secretos de los que necesita para su tarea.
Productos recomendados
Configuración de NAS y servidores
Más para leer
¿Puede un servidor en una residencia estudiantil funcionar lo bastante silenciosamente como para dormir, estudiar y hacer videollamadas?
Sí, un servidor para una residencia universitaria puede pasar desapercibido si el hardware consume poca energía, se controlan las vibraciones del almacenamiento, se programan...
Un laboratorio doméstico estudiantil que puede pasar de la habitación de la residencia universitaria al primer apartamento
Mantén portátil el laboratorio doméstico de un estudiante separando los servicios de la red específica de cada habitación, minimizando el hardware, haciendo copias de...
Cómo compartir un servidor doméstico con tus compañeros de piso sin compartir cuentas ni archivos privados
Asigna a cada compañero de piso una identidad con nombre, almacenamiento privado y solo los roles compartidos que necesite; mantén la administración, las copias...
