Versionado & Build

Versionado independiente

Los proyectos Lino pueden contener varios servicios y aplicaciones web. Cada elemento desplegable tiene su propia versión, por lo que una corrección pequeña en un servicio no fuerza un release artificial de todo el sistema. Esto es importante en arquitecturas modulares y distribuidas, donde APIs, workers, web apps, migrations y contratos de integración pueden evolucionar a ritmos diferentes.

La versión operativa se almacena en un archivo de texto simple llamado version.txt. Para servicios, el archivo queda en src/Services/<ServiceName>/version.txt. Para aplicaciones web, queda en src/WebApps/<WebAppName>/version.txt. El CLI de Lino lee estos archivos al listar, consultar, incrementar y generar builds versionados.

Regla SemVer usada por Lino

MAJOR.MINOR.PATCH

• PATCH incrementa el último número y debe usarse para correcciones compatibles, pequeñas mejoras internas y cambios que no alteran el contrato público.
• MINOR incrementa el número del medio y reinicia patch a cero. Úsalo para funcionalidades retrocompatibles, nuevos endpoints, campos opcionales o comportamiento aditivo.
• MAJOR incrementa el primer número y reinicia minor y patch a cero. Úsalo cuando los consumidores deban adaptarse, por ejemplo porque un contrato de API cambió de forma incompatible o un comportamiento fue reemplazado intencionalmente.

Ejemplos: 1.0.0 puede representar la primera versión estable, 1.0.1 una corrección compatible, 1.1.0 una nueva capacidad compatible o nuevos endpoints sin ruptura, y 2.0.0 un release con cambios que exigen actualización de los clientes.

Consultar versiones actuales

Usa lino version list para ver las versiones actuales de todos los servicios y aplicaciones web del proyecto:

lino version list

Usa lino version show cuando necesites consultar la versión de un servicio o aplicación web específica. El comando pregunta si el objetivo es un servicio o una aplicación web y muestra la versión leída del archivo version.txt correspondiente.

lino version show

Incrementar una versión

Usa lino version bump cuando un servicio o aplicación web esté listo para un nuevo release:

lino version bump

1. Ejecuta el comando desde la raíz del proyecto.
2. Selecciona uno o más servicios o aplicaciones web. El prompt muestra cada elemento con su versión actual.
3. Elige el tipo de incremento: patch, minor o major.
4. Confirma las respuestas. Lino actualiza los archivos version.txt seleccionados y muestra una tabla con las nuevas versiones.

Cada ejecución mantiene un seguimiento claro de cambios, mejora la consistencia con prácticas de release y facilita la alineación con pipelines de CI/CD. El número de versión deja de ser un detalle suelto y pasa a identificar el artefacto desplegable que realmente cambió.

Los cambios de versión deben revisarse junto con el impacto técnico del release. Una migration de base de datos puede estar vinculada a la versión de un servicio, los consumidores de API pueden necesitar notas de contrato y los eventos de integración pueden exigir comprobaciones de compatibilidad. Mantener la versión cerca del elemento desplegable hace que estas decisiones sean explícitas y más fáciles de auditar.

Antes de un incremento major, revisa APIs públicas, contratos de eventos, migrations, compatibilidad de clientes y consumidores externos. Antes de un incremento minor, confirma que el nuevo comportamiento sea aditivo. Antes de un patch, confirma que el cambio sea compatible y no cambie expectativas de uso.

Build y contenerización

En los videos y en el desarrollo diario, dotnet build se usa con frecuencia para validar que la solución generada todavía compila después de cada etapa de modelado. El comando lino build tiene otro objetivo: preparar servicios y aplicaciones web seleccionados para release, publicándolos en modo Release con el perfil de publicación de container de .NET.

Esta separación evita tratar una simple validación de compilación como paquete de entrega. Usa dotnet build durante el desarrollo para encontrar errores temprano. Usa lino build cuando el artefacto esté listo para recibir versión, convertirse en imagen de container y pasar a un registry o pipeline de despliegue.

Qué hace lino build

Ejecuta el comando desde la raíz de un proyecto Lino:

lino build

El CLI valida el usuario autenticado y la configuración actual del proyecto, pregunta qué servicios o aplicaciones web deben entrar en el build y luego pregunta si la versión debe mantenerse o incrementarse. Cuando se selecciona un incremento, Lino actualiza el version.txt correspondiente antes de generar los comandos de build.

El backend devuelve los comandos exactos a ejecutar. Actualmente, estos comandos usan dotnet publish con -c Release, -p:PublishProfile=DefaultContainer, -p:ContainerRepository, -p:ContainerImageTag y -p:ContainerLabelVersion. La tag de la imagen y el label de versión del container reciben el mismo valor SemVer elegido para el release.

En la práctica, el proceso compila el código del servicio o de la aplicación web, aplica la configuración de publicación necesaria, genera una imagen de container basada en la versión SemVer actual y asigna nombre, tag y metadatos estandarizados al artefacto.

Nombres de repositorio generados

Lino normaliza los nombres del proyecto y de los elementos para generar repositorios de container previsibles:

• API de servicio simple: <project-name>/services/<service-name>-api:1.2.3
• Host de servicio modular: <project-name>/services/<service-name>-host:1.2.3
• Aplicación web Blazor: <project-name>/webapps/<webapp-name>:1.2.3

Esta convención mantiene APIs de servicios, hosts modulares y aplicaciones web separados en el registry, preservando la versión de release en la tag. El patrón también elimina decisiones manuales repetitivas y reduce divergencias entre entornos, scripts de CI/CD y documentación operativa.

Publicación en registries

Las imágenes generadas pueden publicarse en el registry usado por tu plataforma de deploy:

• Docker Hub
• GitHub Container Registry
• AWS ECR
• Azure Container Registry
• cualquier otro registry compatible con OCI.

Siempre que sea posible, haz deploy apuntando a tags inmutables de versión, como 1.2.3, en lugar de tags flotantes. Esto mejora rollback, auditoría y comparación entre lo que fue compilado, publicado y desplegado.

Flujo recomendado de release

1. Ejecuta los tests del proyecto y dotnet build para validar el código fuente antes de empaquetar.
2. Consulta las versiones actuales con lino version list y revisa qué servicios o aplicaciones web cambiaron.
3. Usa lino build y elige si la versión actual se mantendrá o recibirá incremento patch, minor o major.
4. Publica las imágenes de container generadas en el registry usado por la plataforma de despliegue, como Docker Hub, GitHub Container Registry, AWS ECR, Azure Container Registry u otro registry compatible.
5. Despliega referenciando tags de versión trazables y mantén changelog, migrations y plan de rollback conectados al mismo release.

No coloques secrets, connection strings de producción ni credenciales específicas de entorno dentro de las imágenes generadas. Usa variables de entorno, user secrets para desarrollo local, bóvedas de secrets de CI/CD o el mecanismo de secrets de la plataforma de deploy.

Con este flujo, versionado y build quedan conectados: el mismo valor SemVer grabado en el proyecto se usa como tag de container y como metadato de release, mejorando la trazabilidad entre código fuente, migrations, contratos de API, eventos de integración y artefactos desplegados.