Me estaba tomando una cerveza mientras peleaba con un merge conflict (otra vez… siempre pasa los lunes, no sé por qué) y me puse a pensar: “¿Qué pasa realmente con este pobre código desde que le doy commit hasta que aparece en producción? ¿Qué odisea vive?” Así que les voy a contar la travesía de nuestro querido código, en 3 actos, como si fuera una película de bajo presupuesto pero con harto corazón.
PARTE 1: El nacimiento y el push
Todo empieza contigo, programador, tipeando frenéticamente mientras suena música épica de fondo. Finalmente le das git add, git commit -m "arreglando cosas jeje" (porque sí, siempre va un “jeje” o un “fix” misterioso), y luego git push.
En ese momento, tu código deja tu computador y sube a ese servidor remoto —GitHub, GitLab, Bitbucket, lo que uses— como quien mete la carta en el buzón. Ahí queda esperando que alguien (o algo) lo lea.
Pero no todo es felicidad… porque el push no es el final, es el inicio de la inspección minuciosa: se activa automáticamente el pipeline de CI/CD, como esos guardias de aeropuerto revisando tu maleta.
★ Tu código ahora entra a la zona de integración continua (CI), donde pasan cosas como:
– Compilación: ¿se arma el proyecto o quedó la embarrada?
– Pruebas unitarias: “a ver si estas funciones hacen lo que prometen o solo fingen”.
– Linting/formatting: porque el código bonito también importa (aunque nadie lo lea).
Si falla algo aquí, el pipeline se detiene, suena la alarma y tu código no avanza. Es como ser rechazado en la aduana por llevar shampoo de más de 100 ml 😅.
Pero si pasa… oh, amigo, tu código entra al siguiente nivel: la tierra prometida de los builds exitosos, y de ahí, empieza a empacar maletas para su verdadero destino…
…y aquí lo dejamos por ahora, porque la historia recién empieza. Bueno, los dejo que mi cerveza se está calentando y eso sí que no se puede tolerar. ¡Pronto les cuento la parte 2 del viaje! 🍻🦡✨
Comentarios
Publicar un comentario