En el subcapítulo anterior insistimos en «fijar siempre la versión» de un módulo. Ahora veremos por qué es tan importante y cómo se hace cuando el módulo es tuyo y vive en un repositorio Git. El versionado de módulos es lo que permite usarlos de forma segura y predecible en equipo, sin que un cambio inesperado rompa tu infraestructura.

Imagina que tu empresa tiene un módulo red-corporativa en un repositorio Git, usado por diez proyectos. Un día, alguien mejora el módulo y cambia cómo crea las subredes. Si los diez proyectos usaran «la última versión» del módulo automáticamente, todos se verían afectados por ese cambio de golpe, sin avisar. El próximo terraform plan de cada proyecto mostraría cambios inesperados... y quizá peligrosos.

Necesitas una forma de decir «yo uso esta versión concreta del módulo, y no cambiará hasta que yo decida actualizar». Eso son las versiones.

Un Git tag (etiqueta de Git) es una marca con un nombre que pones a un punto concreto de la historia de un repositorio. Se usa para marcar versiones. La convención más extendida es el versionado semántico (semantic versioning): números como v1.4.2.

Cada tag es una «foto» estable del módulo en un momento dado. Una vez creado, no cambia: v1.0.0 siempre será exactamente ese código.

El formato vMAYOR.MENOR.PARCHE (ej. v2.3.1) comunica el tipo de cambio:

Así, de un vistazo, sabes el riesgo de actualizar: pasar de v1.2.0 a v1.3.0 (cambio menor) es seguro; pasar a v2.0.0 (cambio mayor) puede requerir ajustes.

Cuando referencias un módulo desde un repositorio Git, indicas qué versión (tag) quieres usar con ref:

Y para los módulos del Registry (subcapítulo 18.3), con el argumento version:

En ambos casos, le dices a Terraform: «usa exactamente esta versión». Aunque el módulo evolucione, tu proyecto seguirá usando la versión que fijaste, estable y predecible, hasta que tú decidas cambiar el número.

Con versionado, cada proyecto controla cuándo actualiza:

Ventajas:

• Estabilidad: tu infraestructura no cambia sin que tú lo decidas.
• Actualizaciones controladas: subes de versión cuando estás preparado, revisando el plan (subcapítulo 12.5) y probando antes.
• Reproducibilidad: cualquiera que ejecute tu código obtiene el mismo resultado, porque la versión del módulo está fijada.
• Trabajo en equipo seguro: distintos proyectos usan distintas versiones sin pisarse.

Ejemplo del mundo real: el equipo de plataforma publica red-corporativa v2.0.0 con una mejora importante pero que requiere ajustes (cambio mayor). En vez de imponerlo a todos de golpe, los equipos de cada proyecto migran a v2.0.0 cuando pueden: leen las notas de la versión, prueban en su entorno de desarrollo, revisan el plan y luego actualizan producción. Nadie se lleva una sorpresa. El versionado convierte una actualización potencialmente caótica en un proceso ordenado.

Esto encaja perfectamente con lo que vimos en el subcapítulo 12.5 (PR review de planes). Actualizar la versión de un módulo es un cambio en el código que pasa por un Pull Request: cambias ref=v1.2.0 a ref=v2.0.0, el CI muestra el plan con lo que eso implica, un compañero lo revisa, y solo entonces se aplica. Versionado + revisión de planes = cambios de infraestructura seguros y trazables.

• Sin versionado, un cambio en un módulo compartido afectaría al instante a todos los proyectos que lo usan, sin control: peligroso.
• Un Git tag marca una versión estable e inmutable del módulo. La convención es el versionado semántico: vMAYOR.MENOR.PARCHE.
• Los números comunican el riesgo: MAYOR = cambios incompatibles (cuidado), MENOR = funcionalidad nueva compatible, PARCHE = correcciones seguras.
• Fijas la versión con ref=vX.Y.Z (módulos Git) o version = "X.Y.Z" (Registry): tu proyecto usa exactamente esa versión hasta que decidas cambiarla.
• Beneficios: estabilidad, actualizaciones controladas, reproducibilidad y trabajo en equipo seguro. Encaja con el flujo de PR review de planes (subcap. 12.5).

En el último subcapítulo del capítulo veremos un dilema de diseño importante: cuándo crear módulos genéricos (muy reutilizables) frente a módulos específicos de tu dominio.