Entrevista técnica: ¿Cómo migrar a Go 1.26 sin romper las toolchains?

Consigna y contexto

Un monorepo de Go con múltiples módulos utiliza Go 1.25. El equipo desea las herramientas y mejoras de runtime de Go 1.26, pero las máquinas de los desarrolladores varían de Go 1.23 a 1.26, CI cuenta con ejecutores de Linux, macOS y Windows, y los usuarios downstream requieren compatibilidad de bibliotecas con versiones más antiguas de Go.

Diseña una migración que contemple la directiva go, la selección de toolchain, el requisito de bootstrap de Go 1.26, los límites de liberación de módulos, una matriz de CI y puertas de rollback.

Qué evalúa el entrevistador

• Si distingues la versión del compilador, la versión del lenguaje en go.mod y las descargas automáticas de toolchains.
• Si identificas cómo el requisito de bootstrap de Go 1.26 afecta las imágenes de construcción y la cadena de self-hosting.
• Si los repositorios con múltiples módulos, el código generado y los consumidores downstream tienen límites explícitos de compatibilidad.
• Si el CI reproducible, los checksums y los artefactos demuestran la seguridad en lugar de limitarse a actualizar el Go local.

Preguntas para clarificar

1. ¿Existen múltiples archivos go.mod, módulos de herramientas y directorios de código generado?
2. ¿Se distribuyen binarios, bibliotecas o ambos? ¿Cuál es la versión mínima de Go para downstream?
3. ¿Puede CI descargar toolchains automáticamente y cómo funciona la compilación offline?
4. ¿Están involucrados cgo, herramientas específicas de la plataforma, compiladores antiguos o imágenes de construcción de terceros?

Respuesta de 30 segundos

Haría un inventario de la versión mínima de soporte de cada módulo, generadores y ejecutores, y luego gestionaría el compilador de Go 1.26, la directiva go y la selección de toolchain por separado. Go 1.26 requiere Go 1.24.6 o posterior para el bootstrap, por lo que las imágenes de construcción y la cadena de self-hosting deben actualizarse primero. Los módulos mantienen la versión de go prometida a downstream hasta que realmente utilicen una característica del lenguaje o biblioteca más reciente. CI fija toolchains, checksums y cachés offline en Linux, macOS y Windows, con pruebas en dos versiones, comparación de artefactos y un canary. El rollback restaura la imagen, el archivo lock y las directivas de módulo de forma conjunta.

Análisis detallado paso a paso

Inventariar versiones y límites

Lista el go, toolchain, directivas replace, generadores, configuraciones de cgo y restricciones de plataforma de cada módulo. Separa las bibliotecas que deben seguir siendo consumibles por versiones antiguas de Go de las herramientas internas que deben construirse con un compilador nuevo, en lugar de elevar todo el monorepo.

Corregir primero la cadena de bootstrap

Go 1.26 requiere Go 1.24.6 o posterior para el bootstrap. Valida las imágenes de builder, los entornos de compilación cruzada y los scripts de self-hosting:

bootstrap Go >= 1.24.6
build Go      = 1.26.x
module go     = lowest promised language version

Compila y prueba en una imagen aislada antes de reemplazar los ejecutores compartidos. Registra los orígenes de descarga y los checksums para que el Go del host nunca se use de manera implícita.

Diseñar la política de go.mod y toolchain

La directiva go expresa la versión del lenguaje del módulo, mientras que toolchain puede expresar una toolchain de compilación recomendada. Una biblioteca no debe elevar su directiva go simplemente porque las herramientas de CI se actualizaron; si utiliza una característica de Go 1.26, eleva la versión del módulo y documenta el mínimo. Las descargas automáticas necesitan un proxy, caché y una política para fallos offline.

Manejar múltiples módulos y código generado

Actualiza primero los módulos de herramientas mientras los módulos de producto conservan su promesa de lenguaje. Fija las versiones de Go de los generadores, los esquemas de entrada y las salidas; compara el formateo, las API exportadas, el comportamiento binario y los metadatos de código fuente antes y después. No permitas que un generador use silenciosamente una toolchain diferente de la máquina de un desarrollador.

Construir una matriz de compatibilidad de CI

Prueba la compilación en Go 1.25 y 1.26, pruebas unitarias, race, verificaciones estáticas y empaquetado en los sistemas operativos soportados. Ejecuta pruebas de consumidores con la versión mínima para bibliotecas y fija 1.26 para binarios internos. Las claves de caché deben incluir la versión de Go, el grafo de módulos y la plataforma para evitar la reutilización de caché entre diferentes versiones.

Canary, observabilidad y rollback

Comienza con un módulo y un canary de ejecutor. Compara el tiempo de compilación, los resultados de las pruebas, los informes de race, los hashes de los artefactos, el comportamiento de inicio y la resolución de dependencias. Si el bootstrap, cgo, la plataforma o la compatibilidad downstream fallan, restaura la imagen anterior, go.mod/toolchain y las claves de caché; cambiar solo el PATH no es un rollback.

Respuesta modelo

La migración debe separar el compilador, la versión del lenguaje y la cadena de bootstrap. Go 1.26 requiere Go 1.24.6 o posterior para el bootstrap, por lo que primero se deben actualizar las imágenes de builder y la compilación cruzada. Las bibliotecas mantienen su directiva go mínima prometida hasta que verdaderamente utilicen una nueva característica del lenguaje o biblioteca; las herramientas internas pueden migrar antes. Fija toolchains, proxies, checksums y cachés, luego prueba Go 1.25/1.26, plataformas soportadas, race y versiones mínimas downstream. Fija las versiones de los generadores y compara los artefactos. Expande a partir de las métricas de canary y haz rollback de la imagen, las directivas de módulo, la toolchain y la caché de manera conjunta para lograr construcciones reproducibles.

Errores comunes

• Actualizar el Go de los desarrolladores ignorando el compilador de bootstrap y la imagen de compilación.
• Tratar la directiva go, la toolchain y la versión del compilador como el mismo concepto.
• Elevar la versión mínima de Go de una biblioteca solo para usar herramientas nuevas en CI.
• Permitir que los generadores y builders dependan del PATH del host, produciendo salidas no reproducibles.
• Omitir la versión de Go y la plataforma de las claves de caché y reutilizar cachés incompatibles.
• Hacer rollback únicamente del PATH sin restaurar go.mod, las imágenes y los checksums de la cadena de suministro.

Preguntas de seguimiento

¿Por qué validar la versión de bootstrap de Go 1.26 por separado?

La cadena de self-hosting usa un Go más antiguo para compilar el nuevo Go. Si la imagen está por debajo de 1.24.6, la actualización falla durante la construcción del compilador independientemente de la compatibilidad del código fuente de la aplicación.

¿Cuándo debe una biblioteca elevar su directiva go?

Cuando su código fuente o su API de la biblioteca estándar realmente requieran la versión más reciente, documentando el mínimo en el contrato de release. Una actualización de CI o de herramientas internas por sí sola no modifica las promesas hechas a downstream.

¿La descarga automática de toolchain resuelve todos los problemas de versiones?

No. Aún requiere acceso a la red, un proxy de confianza, cachés y una política offline; cgo, las herramientas de plataforma y las dependencias de bootstrap deben fijarse por separado.

¿Cómo demuestras que el rollback funciona?

Restaurando realmente la imagen antigua, las directivas de módulo, la toolchain y las cachés en un canary, reconstruyendo y comparando pruebas, hashes de artefactos e instalación downstream, en lugar de limitarse a comprobar cadenas de texto de versiones.