¿Qué son las vistas de fuente?
Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 - TFS 2017
Las vistas de fuente permiten compartir subconjuntos de versiones de paquetes con los consumidores. Un uso común de las vistas de fuente es compartir versiones de paquetes que se han probado y validado, pero que se mantienen en paquetes que todavía están en desarrollo o que no cumplen la barra de calidad.
Vistas de fuente y orígenes ascendentes
Las vistas de fuentes y los orígenes ascendentes están diseñados para funcionar conjuntamente para proporcionar una solución de nivel empresarial para compartir y consumir paquetes.
Para que otras fuentes de Azure Artifacts usen la fuente como origen ascendente, debe establecer la visibilidad de la vista de la fuente para los miembros de la organización o los miembros de la Azure Active Directory, en función de su escenario.
La @local vista
Todas Artifacts de distribución incluyen tres vistas: @local@prerelease , y @release . Las dos últimas son vistas sugeridas que se pueden cambiar o eliminar según sea necesario. @locales la vista predeterminada que se usa normalmente en orígenes @local
La vista contiene todos los paquetes publicados directamente en la fuente (por ejemplo, o ) y todos los paquetes guardados @localnuget push desde orígenes npm publish@local Consulte los gráficos de paquetes para obtener información sobre cómo se construyen los paquetes disponibles.
Vista predeterminada
La Artifacts debe tener una vista predeterminada. Cuando se crea la fuente, la vista predeterminada es @local . Esta vista se usa cuando otras fuentes agregan la fuente como origen ascendente. Para más información sobre por qué los orígenes ascendentes requieren el uso de vistas, consulte el artículo sobre gráficos de paquetes.
Nota
Las vistas de fuente son de solo lectura, lo que significa que los usuarios conectados a una vista solo pueden usar paquetes publicados en esa vista o paquetes guardados previamente desde orígenes ascendentes.
Uso de vistas de fuente para liberar paquetes
Al crear paquetes en escenarios de integración y entrega continuas, es importante transmitir tres fragmentos de información: la naturaleza del cambio, el riesgo del cambio y la calidad del cambio.
Evaluación de la naturaleza y el riesgo del cambio
La naturaleza y el riesgo del cambio pertenecen al propio cambio,es decir, lo que se ha establecido para hacer, ambos se conocen al principio del trabajo. Si va a introducir nuevas características, realizar actualizaciones de las características existentes o aplicar revisiones a los errores; esta es la naturaleza del cambio. Si sigue realizando cambios en la parte de la API de la aplicación; se trata de una faceta del riesgo del cambio. Muchos NuGet usan la notación de versionamiento semántico (SemVer) para transmitir estos dos fragmentos de información. SemVer es un estándar ampliamente utilizado y realiza un buen trabajo de comunicación de este tipo de información.
Determinar y comunicar la calidad del cambio
Por lo general, la calidad del cambio no se conoce hasta que se completa el proceso de validación. Esto se produce después de que el cambio se ha creado y empaquetado. Debido a este detalle, no es factible comunicar la calidad en el número de versión, que se especifica durante el empaquetado y antes de la validación. Hay soluciones alternativas para validar previamente (por ejemplo, consumir los archivos DLL de la compilación directamente antes de empaquetar y publicar los paquetes en un entorno de "depuración" o "CI" y, a continuación, validar y volver a publicar esos paquetes en un entorno de "versión"), pero ninguno de los que hemos visto puede garantizar realmente que el paquete creado cumple el estándar de calidad correcto.
@Release las vistas permiten comunicar la calidad de un paquete una vez validado. Cree paquetes compatibles con SemVer en CI/CD que comuniquen la naturaleza y el riesgo de los cambios mediante la versión del paquete y, a continuación, promueva el paquete en una vista de versión para mostrar a los consumidores que es de una calidad determinada (por ejemplo, @prerelease@release , , etc.). Por lo tanto, una vista de versión permite a los consumidores ver solo el subconjunto de versiones de cada paquete que se prueban, validan y están listas para usarse.
