Dónde se pierde el tiempo de un desarrollador sin CI/CD, pruebas automatizadas y un entorno de desarrollo

En un equipo sin entrega automatizada, el desarrollador realiza a diario operaciones no relacionadas con escribir código: compila el proyecto manualmente, verifica los cambios a mano, espera a que se libere el entorno, corrige errores encontrados una semana después de su aparición. En el registrador de tareas estos costes no se reflejan: la tarea está todo ese tiempo en estado «en progreso». El responsable ve solo el resultado: los plazos de entrega aumentan con la misma plantilla del equipo.

En el artículo se describen seis lugares donde se pierde tiempo, cómo medir las pérdidas en una semana y el orden de implantación de la automatización.

Términos

CI (continuous integration) — compilación y verificación automática de cada cambio enviado al repositorio.

CD (continuous delivery) — entrega automática de la compilación verificada al entorno de pruebas o a producción.

Pipeline — secuencia de pasos descrita en un archivo dentro del repositorio: compilación, pruebas, análisis de código, despliegue. El pipeline se ejecuta automáticamente con cada cambio. Lo ejecutan GitLab CI, GitHub Actions, Jenkins y sistemas similares.

SAST (static application security testing) — búsqueda de vulnerabilidades en el código fuente sin ejecutarlo.

SCA (software composition analysis) — comprobación de librerías de terceros frente a bases de datos de vulnerabilidades conocidas.

Дев-стенд — entorno en el que funciona la versión actual de la aplicación desde la rama principal. El tester, el gestor y el cliente revisan en él el resultado antes del lanzamiento.

1. Compilación y despliegue manual

El despliegue manual consiste en diez–veinte pasos: obtener el código, compilar, copiar archivos al servidor, aplicar migraciones de base de datos, reiniciar servicios, comprobar el resultado. Un despliegue lleva entre 20 y 60 minutos. La secuencia de pasos suele conocerla una o dos personas, y el resto de desarrolladores esperan a que esas personas estén disponibles.

Un paso omitido lleva a una avería. Buscar la causa lleva más tiempo que el propio despliegue, porque no hay un registro de acciones.

Como el despliegue es laborioso, el equipo lo hace raramente. En dos–tres semanas se acumulan decenas de cambios y se lanzan en un único release. Si falla tras ese release, la causa se busca entre todos esos cambios. Si se despliega cada cambio por separado, la causa se conoce de inmediato: es el último cambio.

En el pipeline los mismos pasos están escritos en un archivo y se ejecutan de forma idéntica en cada ejecución. Cualquiera del equipo puede lanzar el despliegue. El rollback se realiza volviendo a ejecutar el pipeline para la versión anterior.

2. Verificación manual en lugar de autotests

Sin autotests, el desarrollador tras cada cambio verifica a mano su propia tarea y las funciones adyacentes que el cambio pudo afectar. Nadie revisa todo el sistema antes del release: una verificación manual completa lleva días.

Un usuario detecta el error en una función no verificada. Desde la aparición del error hasta su notificación pasan desde varios días hasta varias semanas. Durante ese tiempo el desarrollador ha pasado a otras tareas. Para corregirlo vuelve a leer su propio código, recupera la lógica de la solución y busca el cambio que causó el error. Corregir ese mismo error diez minutos después del commit lleva menos tiempo porque el desarrollador recuerda el código.

Los autotests reducen ese intervalo al tiempo del pipeline. No se requiere cobertura completa. El efecto principal proviene de pruebas sobre escenarios que generan ingresos: registro, realización de un pedido, pago.

3. Ausencia de entorno de desarrollo

Sin un entorno de desarrollo, solo el propio desarrollador ve el resultado en su ordenador. La configuración de su máquina difiere de la del servidor: otras versiones de librerías, otros datos, otras configuraciones. Parte de los errores se manifiesta solo en el servidor, es decir, después del release.

El tester y el gestor acceden al resultado tras desplegar en producción. Los comentarios sobre la interfaz y la lógica llegan cuando la función ya está disponible para los usuarios. Cada comentario implica otro ciclo de desarrollo y otro despliegue.

Un entorno compartido para todo el equipo resuelve el problema parcialmente. Los desarrolladores lo usan por turno, y desplegar una rama sobrescribe los cambios de la anterior. La práctica actual es un entorno temporal por cada solicitud de fusión (preview environment, en GitLab — review app). El pipeline lo crea al abrir la solicitud, publica el enlace en la conversación y elimina el entorno tras la fusión. El revisor abre el enlace y ve exactamente el cambio que está comprobando.

4. Vulnerabilidades detectadas tarde

Sin análisis de código en el pipeline, las vulnerabilidades se encuentran en tres ocasiones: en una auditoría externa, durante la revisión por el equipo de seguridad del cliente o tras un incidente. Para entonces, ya se han construido otras funciones sobre el código vulnerable. Corregirlo afecta a todas esas funciones y requiere volver a verificarlas.

Un caso aparte es una contraseña o clave de acceso que entra en el repositorio. No se puede eliminar con un commit; permanece en el historial. Es necesario revocar la clave, actualizarla en todos los sistemas donde se usó y revisar los registros de acceso durante todo el periodo de fuga. Esto lleva uno–dos días laborables.

La comprobación automática en el pipeline incluye tres partes:

• búsqueda de secretos (gitleaks, herramientas integradas de GitLab y GitHub) bloquea el commit con la clave antes de que llegue a la rama principal;
• SCA (Trivy, osv-scanner, Dependabot, Renovate) notifica sobre una librería vulnerable y crea una solicitud para actualizar la versión;
• SAST (Semgrep, CodeQL, analizadores de GitLab) encuentra en el código construcciones inseguras: inserción de entrada del usuario en una consulta SQL, verificación de certificado desactivada, deserialización insegura.

El desarrollador ve el aviso en la solicitud de fusión pocos minutos después de enviar el código y lo corrige dentro de la misma tarea. Este enfoque se llama shift left: la comprobación de seguridad se traslada de la etapa previa al release a la etapa de escritura del código.

5. Ramas de larga vida

Sin comprobación automática rápida, los desarrolladores integran código con poca frecuencia. Una rama existe dos–tres semanas y en ese tiempo se diverge de la rama principal. La fusión provoca conflictos; resolverlos lleva horas. Los errores introducidos al resolver conflictos pasan desapercibidos porque no hay autotests.

La práctica de trunk-based development supone ramas que viven no más de uno–dos días e integración en la rama principal por pequeñas porciones. Las funciones incompletas se ocultan con conmutadores (feature flags) y no están disponibles para los usuarios. Esta práctica solo funciona con un pipeline: cada fusión debe verificarse automáticamente en minutos.

6. Esperas y cambio de contexto entre tareas

Cada uno de los puntos anteriores genera esperas: por el colega que sabe desplegar, por un entorno libre, por el resultado de una verificación manual, por la respuesta del revisor. Mientras espera, el desarrollador coge una segunda tarea. Tras recibir la respuesta vuelve a la primera y pierde tiempo recuperando el contexto. Con varias esperas al día el desarrollador no tiene intervalos continuos de trabajo mayores de una hora.

El modelo DevEx (Нода, Стори, Форсгрен, Грайлер, 2023) describe la productividad del desarrollador con tres factores: velocidad de retroalimentación, carga cognitiva y posibilidad de trabajo continuo concentrado. La falta de automatización empeora los tres. La retroalimentación llega en días. Hay que retener en la memoria el orden de operaciones manuales. La jornada se fragmenta en esperas.

Impacto de los asistentes IA

Con un asistente IA el desarrollador escribe código más rápido y la cantidad de cambios por unidad de tiempo aumenta. La velocidad de la verificación manual y del despliegue manual sigue igual. La cola de cambios no verificados se incrementa y el plazo de entrega viene determinado por la verificación y el despliegue.

Los informes DORA de 2024 y 2025 registran esta dependencia. El aumento del uso de IA va acompañado de una caída de la estabilidad de las entregas en equipos sin verificaciones automáticas. Conclusión del informe de 2025: la IA potencia propiedades ya existentes del proceso de desarrollo, tanto las fuertes como las débiles. Por eso conviene configurar pruebas automáticas y análisis de código antes o al mismo tiempo que la implantación masiva de asistentes.

Cómo medir las pérdidas

La medición lleva una semana laborable. Cada desarrollador anota en una tabla compartida el tiempo en cinco categorías:

1. compilación y despliegue manual;
2. verificación manual antes del release;
3. espera por entorno, despliegue o revisor;
4. corrección de defectos encontrados después del release;
5. resolución de conflictos de fusión.

Ejemplo para un equipo de cinco desarrolladores:

28 horas representan el 14% del fondo semanal de tiempo del equipo (200 horas). Con un coste por hora de desarrollador de 2 500 rublos, son 70 000 rublos por semana, o alrededor de 300 000 rublos al mes. Las cifras del ejemplo son orientativas. La tabla con vuestros datos da la suma con la que comparar el coste de implantar la automatización.

En la tabla no se incluye el tiempo para recuperar el contexto tras los cambios de tarea, por lo que las pérdidas reales son mayores que las medidas.

Orden de implantación

Los pasos están ordenados por relación resultado/esfuerzo decreciente. Cada paso da resultados sin necesitar los siguientes.

1. Pipeline con compilación y linter para cada solicitud de fusión. Es un archivo en el repositorio: .gitlab-ci.yml o el directorio .github/workflows. Plazo — uno–dos días. A partir de entonces, el código que no compile no llega a la rama principal.
2. Despliegue automático de la rama principal al entorno de desarrollo. Plazo — de dos días a una semana, según cuánto esté descrita la configuración del servidor.
3. Autotests para tres–cinco escenarios que generan ingresos. Las pruebas se añaden al pipeline como paso obligatorio. A partir de entonces rige la norma: cada defecto encontrado tras el release se cierra junto con la prueba que lo reproduce.
4. Búsqueda de secretos y SCA. Ambas herramientas se conectan en unas horas y generan pocas falsas alarmas.
5. SAST con un conjunto de reglas limitado. Un analizador con todas las reglas produce cientos de avisos y el equipo deja de leerlos. Esquema de trabajo: activar reglas de alta criticidad, bloquear la fusión solo por ellas, añadir las demás reglas tras depurar los avisos existentes.
6. Entornos temporales para solicitudes de fusión. Este paso requiere contenerizar la aplicación, por lo que conviene dejarlo para el final.
7. Despliegue en producción desde el pipeline con confirmación manual y rollback con un solo comando.

La duración del pipeline debe mantenerse dentro de diez minutos. Con un pipeline más largo el desarrollador vuelve a cambiar de tarea durante la espera. Las principales maneras de acortar el pipeline son cachear dependencias y ejecutar pruebas en paralelo.

Un equipo pequeño no necesita un grupo de plataforma separado ni una orquestación compleja. Los signos de complejidad excesiva están descritos en el artículo sobre la fiabilidad que no necesitas.

Cómo comprobar el resultado

El resultado se evalúa con las métricas DORA. Todas se calculan a partir de los datos del sistema de control de versiones y del pipeline:

• frecuencia de despliegues a producción;
• tiempo de entrega del cambio — desde el commit hasta estar en producción;
• porcentaje de despliegues fallidos — despliegues que requirieron rollback o corrección urgente;
• tiempo de recuperación tras un despliegue fallido;
• porcentaje de retrabajos no planificados — despliegues realizados para corregir defectos.

Se registran valores antes de empezar la implantación y se comparan cada trimestre. Tras un trimestre se repite la medición semanal del apartado «Cómo medir las pérdidas». La diferencia en horas, multiplicada por el coste por hora, da el ahorro en rublos.

Una comprobación adicional es el plazo de incorporación de un nuevo desarrollador. Con el pipeline activo, un nuevo empleado envía su primer cambio a producción en la primera semana de trabajo. Señales relacionadas de procesos que frenan al equipo están descritas en el artículo sobre cinco señales de infraestructura que obstaculizan el crecimiento.

La configuración del pipeline, los autotests, el análisis de código y los entornos forman parte de mis servicios. Para evaluar el volumen de trabajo se necesita acceso al repositorio y una descripción del procedimiento actual de despliegue.