No escribo esto contra la IA, porque yo también la uso a diario. Lo escribo porque ha dejado a la vista un problema que estas empresas arrastraban desde hace años y que, con el ritmo de antes, se podía ir capeando.

Y no es un problema solo de empresas pequeñas. He trabajado en consultoras grandes que tenían todo esto resuelto hace tiempo: integración continua, revisiones de código, entornos de preproducción y un proceso de despliegue que no dependía de la memoria de nadie. Aun así, la IA les está obligando a adaptarse también a ellas, porque esos procesos estaban dimensionados para el ritmo al que escribe código una persona. Si incluso quien ya tenía los procesos tiene que replantearlos, quien no los tenía lo nota mucho más.

Lo que me encuentro

El escenario suele ser parecido. Es una empresa mediana con un equipo de desarrollo reducido, y su forma de trabajar se parece más a un waterfall que a otra cosa, aunque las tareas vivan en un tablero Kanban o similar. Esté el código en Subversion o en Git, he visto equipos con GitHub o GitLab que siguen subiendo directamente a la rama principal, sin pull requests, con un pipeline que nadie mira o sin pipeline, y desplegando a mano igual que con SVN. Tener la herramienta no es usarla. Tampoco hay tests automáticos. La documentación que hay en el repositorio la escribió alguien hace tiempo y nadie la ha vuelto a tocar.

Al desplegar, aparecen las cosas que no están en el código:

• una variable de entorno nueva que hay que dar de alta en el servidor.
• una consulta que se ejecuta antes de subir, y otra después para comprobar la integridad de los datos.
• una migración de base de datos que alguien lanza a mano.
• una Lambda que también hay que actualizar, o que hay que ejecutar una vez.

Lo que más me ha llamado la atención es otra cosa. Quien despliega no siempre ha mirado las tareas que está desplegando. Ni hay ningún paso del proceso que le obligue a hacerlo. Sube lo que hay en el repositorio, y lo que esas tareas necesitaban para funcionar depende de que alguien se acuerde de avisarle o de que se lea un comentario sobre la tarea en el tablero.

Dos casos recientes

El primero es de esta misma semana. Se subieron cambios y, de repente, algo dejó de funcionar. Revisamos lo que había cambiado y nada en el código podía provocar ese fallo. La única explicación que encontramos fue de tiempos: durante el despliegue convivieron código antiguo y código nuevo. En ese proyecto hay migraciones y Lambdas de mantenimiento que se ejecutan de forma periódica, y lo más probable es que alguna se lanzara justo en ese hueco, con su código o el de la aplicación todavía en la versión anterior. No podemos asegurarlo al cien por cien, y eso es precisamente lo preocupante: nadie tenía apuntado qué se ejecuta solo, cuándo, ni en qué orden había que actualizar cada pieza.

El segundo es de otra empresa, que trabaja con Subversion sin ramas: todo el mundo sube a la misma línea, y a veces se suben cambios a medias, con parte de los archivos olvidados en la copia local de quien hizo el commit. Cuando termino un desarrollo para ellos, siempre hago lo mismo antes de subir nada: actualizo desde Subversion, compilo, pruebo lo que he desarrollado, ajusto si hace falta y, si funciona, hago el commit. Pero si en el repositorio faltan archivos de otra persona, el build falla, o tengo que esperar a que alguien los suba. Y el caso peor es el contrario: que el build pase, que el despliegue también, y que algo explote en producción sin que nadie se haya dado cuenta.

Ninguno de los dos es un problema de código. Los dos son problemas de proceso.

Por qué la IA lo empeora sin tener la culpa

Antes, la propia lentitud hacía de control sin que nadie lo pretendiera. Si una persona tardaba una semana en sacar una funcionalidad, tenía tiempo de saber qué tocaba, y el despliegue de esa semana llevaba dos o tres cambios que todo el mundo conocía.

Ahora, en esa misma semana entran muchos más cambios, y cada uno puede traer su propio requisito de despliegue. Además, con el código generado pasa algo nuevo: el desarrollador puede aceptar un cambio que lee una variable de entorno nueva o que da por hecha una columna que no existe, sin haberse quedado con ese detalle. Lo sabía el código, pero la persona no lo tenía en la cabeza, y menos aún el que despliega.

Así que el cuello de botella se ha movido. Escribir el código ha dejado de ser lo lento. La pregunta ahora es cuántos cambios podemos llevar a producción sabiendo lo que hacemos.

El problema de fondo: lo que hace falta para desplegar no está escrito en ningún sitio

La tarea del tablero dice qué se ha hecho: «Añadir autenticación con el proveedor nuevo». Lo que no dice es cómo se despliega: si hay que crear una tabla, qué variable falta en producción o qué hay que comprobar después. Esa información está en la cabeza de quien hizo la tarea o en un mensaje que se perdió hace dos semanas.

Hay una pregunta que uso como prueba: ¿dónde está escrito qué hay que hacer para desplegar esta tarea? Si la respuesta es «pregúntale a tal persona», el proceso depende de que esa persona esté y se acuerde. Y el día que falta o se le olvida un paso, el problema aparece en producción.

Lo que propongo, por orden y sin cambiar de herramientas

La buena noticia es que las empresas pequeñas pueden aprovechar los mismos flujos que usan las grandes, adaptados a su tamaño. Y gracias a la IA, implantarlos es mucho más sencillo que antes: el pipeline, el script de comprobación o la configuración de las migraciones son justo el tipo de código que la IA escribe bien y que antes nadie tenía tiempo de preparar.

No hace falta migrar a Git si estás en Subversion, ni cambiar de plataforma si ya usas GitHub o GitLab, ni montar Kubernetes para empezar. Lo que les propongo a estas empresas, en este orden, es lo siguiente.

1. Notas de despliegue en cada tarjeta

Es lo más sencillo y lo que más cambia. Cada tarjeta del Kanban lleva una plantilla fija, que rellena quien hace la tarea:

NOTAS DE DESPLIEGUE
¿Migración o SQL?            no / sí → cuál y cuándo (antes o después)
¿Variables de entorno?       no / sí → nombre y en qué entornos
¿Lambdas u otros servicios?  no / sí → cuál y qué hay que hacer
¿Procesos programados?       no / sí → cuáles; ¿se paran mientras se despliega?
¿Cómo se comprueba?          qué mirar en producción después de subir
¿Cómo se deshace?            qué hacer si algo sale mal

NOTAS DE DESPLIEGUE
¿Migración o SQL?            no / sí → cuál y cuándo (antes o después)
¿Variables de entorno?       no / sí → nombre y en qué entornos
¿Lambdas u otros servicios?  no / sí → cuál y qué hay que hacer
¿Procesos programados?       no / sí → cuáles; ¿se paran mientras se despliega?
¿Cómo se comprueba?          qué mirar en producción después de subir
¿Cómo se deshace?            qué hacer si algo sale mal

La regla es que la tarjeta no pasa a «Listo para desplegar» sin la plantilla rellena, aunque en todas las respuestas ponga «no». Escribir «no» también es información, porque significa que alguien se lo ha preguntado.

2. Una release, no un puñado de tarjetas

Quien despliega no debería tener que recorrer el tablero. Antes de cada despliegue se junta en un único documento lo que sube y lo que piden sus notas:

RELEASE 2026-10-08
Tareas: PROJ-1842, PROJ-1847, BUG-921

Antes:   variable PAYMENT_API_URL en producción
Durante: migración de la tabla customers
         actualizar la Lambda de notificaciones
Después: login, alta de cliente de prueba, /health
Si falla: volver a la revisión anterior; la migración no borra datos

RELEASE 2026-10-08
Tareas: PROJ-1842, PROJ-1847, BUG-921

Antes:   variable PAYMENT_API_URL en producción
Durante: migración de la tabla customers
         actualizar la Lambda de notificaciones
Después: login, alta de cliente de prueba, /health
Si falla: volver a la revisión anterior; la migración no borra datos

El desarrollador trabaja con tareas; quien despliega, con releases. Ese documento es además lo que, dentro de un mes, te dice qué se subió un martes cualquiera.

3. Que el repositorio sepa a qué tarea pertenece cada cambio

Una convención sencilla: todo cambio lleva el identificador de la tarea. Cómo se consigue depende del repositorio.

Con Git, lo natural es que cada tarea vaya en su rama y entre en la principal mediante una pull request (merge request en GitLab) con el id en el título. La rama principal se protege para que nadie suba directamente, y la revisión de la pull request es el momento de preguntar por las notas de despliegue. GitHub y GitLab lo traen de serie; solo hay que activarlo.

Con Subversion, para que no dependa de la buena voluntad, un hook pre-commit en el servidor rechaza los commits cuyo mensaje no empiece por el id:

#!/bin/sh
REPOS="$1"
TXN="$2"
svnlook log -t "$TXN" "$REPOS" | grep -qE '^[A-Z]+-[0-9]+' || {
  echo "El mensaje tiene que empezar por el id de la tarea (PROJ-123)." >&2
  exit 1
}

#!/bin/sh
REPOS="$1"
TXN="$2"
svnlook log -t "$TXN" "$REPOS" | grep -qE '^[A-Z]+-[0-9]+' || {
  echo "El mensaje tiene que empezar por el id de la tarea (PROJ-123)." >&2
  exit 1
}

Y antes de cada commit, svn status: los archivos marcados con ? no están bajo control de versiones. Si alguno es tuyo, falta en el commit. Es el segundo caso de arriba, resuelto con un comando.

A partir de ahí, svn log entre dos revisiones, o git log entre dos etiquetas, te da la lista de tareas que entran en un despliegue, y la release se puede comprobar contra ella. Si sale una tarea que nadie había apuntado, mejor verlo antes de desplegar que después.

4. Las migraciones, en una herramienta y no en un correo

«Antes de subir, ejecuta esta SQL» es probablemente la instrucción que más sustos da. Herramientas como Flyway o Liquibase guardan las migraciones como archivos versionados junto al código y registran en una tabla de la propia base de datos cuáles se han aplicado (flyway_schema_history en Flyway, DATABASECHANGELOG en Liquibase). Así no hay que acordarse de qué se ha ejecutado en cada entorno, porque la base de datos lo sabe.

Y, por lo que contaba en el primer caso, conviene que cada migración funcione también con la versión anterior del código, porque durante el despliegue van a convivir. Si una columna cambia de nombre, primero se añade la nueva; la versión siguiente deja de usar la antigua, y solo después se borra. Así da igual qué pieza se actualice antes, o qué proceso programado se ejecute en medio.

5. Comprobar la configuración antes de tocar nada

El clásico: todo funciona en desarrollo y en producción falla porque faltaba una variable. Un script de veinte líneas que se ejecuta antes del despliegue y lo para si falta algo evita media hora de buscar el error:

#!/bin/bash
for v in PAYMENT_API_URL NOTIFICATION_QUEUE_URL DB_URL; do
  if [ -z "${!v}" ]; then
    echo "Falta $v: no se despliega." >&2
    exit 1
  fi
done
echo "Configuración completa."

#!/bin/bash
for v in PAYMENT_API_URL NOTIFICATION_QUEUE_URL DB_URL; do
  if [ -z "${!v}" ]; then
    echo "Falta $v: no se despliega." >&2
    exit 1
  fi
done
echo "Configuración completa."

Es mucho mejor que el despliegue no empiece que descubrir el fallo con producción a medias.

6. Unas pocas comprobaciones después, siempre las mismas

No hace falta una batería de tests para empezar. Basta con tres o cuatro comprobaciones de humo, siempre las mismas: que responde /health, que se puede iniciar sesión y que la operación principal funciona. Primero como lista en la release, y cuando sea posible, como script.

7. Y entonces, automatizar

Cuando lo anterior funciona a mano, es el momento de llevarlo a un pipeline que compile, ejecute el script de variables, aplique las migraciones, despliegue y lance las comprobaciones. La herramienta depende de dónde esté el código: si usas GitHub o GitLab, GitHub Actions o GitLab CI ya vienen incluidos y no hay que instalar nada; con Subversion, Jenkins trabaja con él sin problema. Aunque solo compile, un pipeline que se ejecuta con cada commit ya merece la pena: si alguien deja archivos sin subir, el aviso le llega a él en minutos, y no a la siguiente persona que actualice. Automatizar un proceso que todavía no está escrito solo sirve para equivocarse más rápido. Primero se escribe y luego se automatiza.

La IA, también del lado del despliegue

Si la IA ha acelerado los cambios, lo lógico es que ayude también a controlarlos. Y aquí le veo mucho recorrido, más allá de escribir código.

Para empezar, ayuda a montar todo lo anterior. Escribir el pipeline, el hook, el script de variables o las primeras migraciones era trabajo que en un equipo pequeño siempre quedaba para «cuando haya tiempo», y con la IA se hace en una tarde. Revisándolo, claro.

También sirve para revisar lo que va a subir. Un uso que estoy probando con empresas más antiguas con SVN, y que me parece de los más interesantes, es pasarle el diff (svn diff -r 1200:1215, o git diff main...rama en Git) y pedirle que liste lo que ese cambio necesita para desplegarse: variables de entorno que se leen por primera vez, tablas o columnas nuevas, llamadas a servicios externos, cambios en una API, procesos programados afectados. Si encuentra una variable nueva que nadie ha apuntado en la tarjeta, ahí hay una conversación pendiente antes de subir.

Y el paso siguiente es que todo esto no dependa de que alguien se acuerde de pedírselo. Las herramientas de IA para desarrollo ya permiten empaquetar un procedimiento en una skill, unas instrucciones que la IA sigue siempre igual: qué leer, qué preguntar y qué plantilla rellenar. O encargárselo a un agente especializado. Es algo que ya uso en mis proyectos personales, donde tengo el control sobre cómo se hacen las cosas, y es donde he comprobado que funciona. Con skills y agentes, los pasos de este artículo se pueden automatizar también:

• Notas de despliegue. Al cerrar una tarea, una skill lee el diff y la tarjeta, rellena la plantilla y marca lo que no cuadra: una variable que el código lee y la tarjeta no menciona, una migración sin plan de vuelta atrás.
• Documento de la release. Antes de desplegar, junta las notas de todas las tareas que entran, las ordena en antes, durante y después, y las contrasta con el svn log o el git log para avisar si sube algo que no está en el tablero.
• Revisión previa. Un agente repasa la release completa con la lista de comprobaciones y deja escrito qué ha verificado y qué no ha podido verificar.

Lo que no cambia es quién decide. La IA prepara, contrasta y avisa; la decisión de desplegar y la responsabilidad siguen siendo de una persona. Bien usada, la IA no sustituye ese control, sino que le quita el trabajo tedioso que hacía que nadie lo hiciera.

Lo que no haría

No empezaría cambiando de herramientas. Si ya usas Git, el problema no es Git: es no usar lo que la plataforma ya ofrece. Y si estás en Subversion, migrar a Git, implantar Scrum o montar un clúster puede tener sentido más adelante, pero en un equipo pequeño que ya va justo, meter todo eso a la vez suele acabar en un proceso nuevo que nadie sigue, junto al antiguo, que sigue funcionando por debajo.

Lo que funciona es lo poco y constante: la plantilla en la tarjeta, la release escrita y la regla en el repositorio, sea un hook o una rama protegida. Son cosas que se pueden implantar en una semana y que cambian la pregunta de «¿alguien se acuerda de lo que había que hacer?» a «¿dónde lo pone?».

Para cerrar

Durante años el objetivo era programar más rápido, y ya lo estamos consiguiendo. Pero un cambio no está terminado cuando se escribe, sino cuando está en producción, se ha comprobado que funciona y se sabe cómo deshacerlo.

Si tu equipo se reconoce en lo que he contado, mi consejo es empezar por la plantilla de notas de despliegue en las tarjetas.

La entrada La IA acelera el código. ¿Quién controla el despliegue? se publicó primero en SASE Formación.

La buena noticia es que debajo de esos cuatro ciclos hay tres ideas que se repiten en todos, y que no dependen del título que estudies. Si las traes entendidas, el resto del curso deja de ser una sucesión de sorpresas.

Esta guía no es un temario. Es lo mínimo que conviene tener claro —y probado en tu equipo— antes de que la asignatura lo dé por supuesto.

Lo único que necesitas para seguir esta guía

Un ordenador y quince minutos. Nada de instalar entornos enormes: una terminal (la tienes ya) y Git, que es lo único que quizá debas descargar.

• Windows: abre PowerShell o Windows Terminal.
• macOS: abre Terminal.
• Linux: ya sabes dónde está.

1. Tu equipo es un árbol de carpetas

Todo lo demás se apoya aquí. Un sistema de archivos es un árbol: una raíz, carpetas que cuelgan de ella y archivos en las ramas. Cuando un programa «no encuentra el archivo», casi siempre es que le has dado mal la dirección dentro de ese árbol.

Absoluta o relativa: la diferencia que rompe todo

Una ruta absoluta empieza en la raíz y funciona siempre, estés donde estés:

/home/ana/proyectos/web/index.html      (Linux y macOS) 
C:\Users\ana\proyectos\web\index.html   (Windows)

/home/ana/proyectos/web/index.html      (Linux y macOS) 
C:\Users\ana\proyectos\web\index.html   (Windows)

Una ruta relativa empieza donde estás ahora mismo:

web/index.html      dentro de la carpeta proyectos 
../index.html       una carpeta hacia arriba
./index.html        aquí mismo

web/index.html      dentro de la carpeta proyectos 
../index.html       una carpeta hacia arriba
./index.html        aquí mismo

La relativa es más corta y más portable —funciona en el equipo de tu compañero, donde tu carpeta personal se llama distinto—, pero depende de dónde estés parado. Esa es la causa número uno del «a mí me funcionaba».

Los tres comandos que se usan todos los días

pwd     # ¿dónde estoy?   (en PowerShell también vale: pwd) 
ls      # ¿qué hay aquí?  (en CMD: dir)
cd web  # entra en la carpeta web
cd ..   # sube una carpeta

pwd     # ¿dónde estoy?   (en PowerShell también vale: pwd) 
ls      # ¿qué hay aquí?  (en CMD: dir)
cd web  # entra en la carpeta web
cd ..   # sube una carpeta

Pruébalos ahora. No hace falta entender nada más: solo moverte y saber siempre en qué rama del árbol estás.

2. Tu trabajo necesita historial, no copias

El patrón que todos hemos hecho alguna vez:

practica.zip
practica_v2.zip 
practica_v2_BUENA.zip
practica_v2_BUENA_final.zip

practica.zip
practica_v2.zip 
practica_v2_BUENA.zip
practica_v2_BUENA_final.zip

Ese sistema falla en tres cosas a la vez: no sabes qué cambió entre una y otra, no puedes volver a un punto concreto, y si trabajáis dos, alguien pisa el trabajo del otro.

Git resuelve exactamente eso. Guarda cambios en lugar de copias, y cada guardado —un commit— lleva fecha, autor y una frase explicando qué hiciste.

El primer repositorio, en cuatro órdenes

La primera vez, y solo la primera, dile a Git quién eres. Si te lo saltas, el primer commit fallará con un «Author identity unknown» que desconcierta a medio aula:

git config --global user.name "Tu Nombre" 
git config --global user.email "tucorreo@ejemplo.com"

git config --global user.name "Tu Nombre" 
git config --global user.email "tucorreo@ejemplo.com"

Y ya, en la carpeta de tu práctica:

git init                      # crea el repositorio 
git add .                     # prepara los cambios
git commit -m "Primera versión de la práctica"
git log --oneline             # mira tu historial

git init                      # crea el repositorio 
git add .                     # prepara los cambios
git commit -m "Primera versión de la práctica"
git log --oneline             # mira tu historial

Cuatro líneas y tienes historial. La cuarta es la que engancha: ahí está tu trabajo con su fecha y su frase, y podrás volver a ese punto cuando quieras.

Git no es GitHub

Se confunden constantemente y conviene separarlo desde el primer día:

• Git es el programa que llevas instalado. Funciona sin internet, en tu equipo.
• GitHub (o GitLab, o Bitbucket) es una web donde puedes alojar una copia de tu repositorio para compartirlo o tenerlo a salvo.

Puedes usar Git toda la carrera sin abrir GitHub. Al revés no.

3. Tus máquinas hablan por la red

Escribes un nombre, pulsas enter y aparece una web. Por debajo pasan tres cosas, y son las mismas tanto si acabas administrando servidores como si programas la web que vive en ellos.

La dirección, la puerta y la traducción

• La dirección es la IP. Dentro de tu casa, cada aparato tiene una IP privada (192.168.1.37 y parecidas, los rangos los fija la RFC 1918). De cara a internet, todos comparten una sola IP pública.
• La puerta es el router. Une tu red local con internet y traduce las direcciones privadas a la pública al salir. Eso es NAT: veinte aparatos dentro, una sola IP fuera.
• La traducción es el DNS. Nadie memoriza números: el DNS convierte saseformacion.es en la IP donde está. Y tu equipo guarda la respuesta un rato en caché, así que la segunda visita no vuelve a preguntar.

Míralo en tu propio equipo

ipconfig                        # Windows: tu IP privada y la puerta de enlace 
ifconfig                        # macOS
ip a                            # Linux
nslookup saseformacion.es       # qué IP hay detrás de un nombre

ipconfig                        # Windows: tu IP privada y la puerta de enlace 
ifconfig                        # macOS
ip a                            # Linux
nslookup saseformacion.es       # qué IP hay detrás de un nombre

La «puerta de enlace predeterminada» que sale en ipconfig es la IP de tu router. Normalmente, 192.168.1.1.

Y entonces, ¿qué distingue a cada ciclo?

Las tres ideas anteriores las vas a usar en los cuatro títulos. Lo que cambia es hacia dónde profundizas:

Dos detalles que ahorran disgustos al elegir:

• DAW y DAM comparten casi todo el primer curso. Si dudas entre los dos, el primer año te sirve igual.
• El reparto de módulos entre 1.º y 2.º lo decide cada comunidad autónoma, no el título estatal. Dos centros pueden dar el mismo módulo en cursos distintos, así que la guía buena es la de tu centro.

Los cinco errores del primer mes

1. Confundir ruta absoluta con relativa. El archivo existe; lo que falla es desde dónde lo buscas.
2. Usar carpetas con copias en vez de commits. _final_BUENA no es una versión, es una esperanza.
3. Creer que Git y GitHub son lo mismo. Uno es el programa; el otro, una web donde dejar una copia.
4. Pensar que el DNS es el hosting. El hosting es donde vive la web; el DNS solo dice en qué IP está. Cambiar uno no mueve el otro.
5. Copiar comandos sin saber dónde estás. Antes de ejecutar nada, pwd.

Ejercicio de cinco minutos

Hazlo entero, en este orden. Si los cuatro pasos te salen, llegas al primer día con más base que la mayoría de la clase:

1. Abre la terminal y ejecuta pwd. Crea una carpeta practicas, entra en ella y vuelve a ejecutarlo. ¿Ves cómo cambia la ruta?
2. Dentro, crea un archivo de texto cualquiera. Ejecuta git init, git add . y git commit -m "Primer commit".
3. Ejecuta git log --oneline. Ese es tu historial.
4. Ejecuta nslookup saseformacion.es y ipconfig (o ip a). Localiza tu IP privada y la IP pública del sitio.

Por dónde seguir

Cada una de las tres ideas tiene su vídeo de un minuto, por si prefieres verlo antes de leerlo:

• Qué estudiarás en SMR, DAW, DAM y ASIR — los módulos reales de cada ciclo, uno por uno.
• Git: qué problema resuelve — los commits en movimiento, y la diferencia con GitHub.
• IP, router y DNS — la cadena completa desde que pulsas enter.

Y si algo de esto se te atraganta ya en septiembre, en SASE Formación damos clases de informática y programación, presenciales y online. La primera clase de prueba es gratuita, y en informática las clases son individuales. Escríbenos y nos cuentas por dónde vas: teléfono y WhatsApp 656 251 438.

La entrada Guía de arranque: lo que se repite en todos los ciclos de informática se publicó primero en SASE Formación.