¿Qué son las vistas de fuente?

Servicios de Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022

Las vistas de flujo permiten a los desarrolladores compartir un subconjunto específico de versiones de paquete con los consumidores. Esto resulta útil cuando desea proporcionar acceso a los paquetes que se han probado y validado, mientras se retienen los que aún están en desarrollo o que no cumplen los estándares de calidad.

Importante

Los feeds públicos dependen de los proyectos públicos. A partir de 2027, los proyectos públicos existentes se convertirán automáticamente en privados. Cuando esto sucede, las fuentes públicas ya no serán accesibles públicamente porque heredan la visibilidad del proyecto de hospedaje. Para obtener más información, consulte Retirada de proyectos públicos.

Vista predeterminada

Cada feed de Artifacts incluye tres vistas de forma predeterminada: @local, @prerelease y @release. Las dos últimas son vistas sugeridas que puede renombrar o eliminar según lo necesite.

@local es la vista predeterminada y se usa normalmente en fuentes ascendentes. Puede cambiar la vista predeterminada en Configuración de Fuentes>Vistas, pero tenga en cuenta que esto no habilita la publicación directa en esa vista. Los paquetes solo se pueden publicar en la fuente de base, donde estarán disponibles en la vista @Local.

La @local vista contiene:

  • Todos los paquetes publicados directamente en el feed.
  • Todos los paquetes guardados desde fuentes de origen.

Las vistas del feed son de solo lectura, lo que significa que los usuarios conectados a una vista solo pueden utilizar los paquetes publicados en dicha vista y/o los paquetes guardados previamente desde fuentes de origen. Consulte gráficos de paquetes para obtener información sobre cómo se construyen los gráficos de paquetes.

Nota

Azure Artifacts solo admite la publicación y restauración de paquetes desde y en la vista predeterminada: @Local.

Vistas de fuente y orígenes de nivel superior

Las vistas del feed y las fuentes de origen están diseñadas para funcionar conjuntamente con el fin de proporcionar una solución de nivel empresarial para compartir y utilizar paquetes. Para permitir que otros feeds de Azure Artifacts usen su feed como fuente upstream, debe establecer la visibilidad de su feed en los miembros de la organización o los miembros de su Microsoft Entra ID, en función de su escenario.

Si eliges Microsoft Entra ID, todas las personas de tu organización podrán acceder a tu feed, y todos los feeds de tu organización y de otras organizaciones asociadas al mismo inquilino de Microsoft Entra podrán realizar envíos ascendentes a tu feed.

Nota

Todas las vistas de un feed público son accesibles para cualquier persona en Internet mientras el proyecto de hospedamiento siga siendo público. A partir de 2027, los proyectos públicos existentes se convertirán automáticamente en fuentes privadas y las fuentes públicas ya no serán accesibles públicamente.

Publicar paquetes con vistas de fuente

Al publicar paquetes, es importante comunicar tres aspectos clave:

Al crear paquetes de versión, es importante transmitir tres fragmentos de información:

  • Naturaleza del cambio: qué tipo de cambio se está introduciendo.

  • Riesgo del cambio: Qué tan disruptivo o crítico podría ser el cambio.

  • Calidad del cambio: indica si el paquete cumple los estándares de validación.

Diagrama que muestra los números de versión semánticos a la izquierda y una etiqueta de calidad preliminar a la derecha para distinguir la naturaleza del cambio de calidad.

Naturaleza y riesgo del cambio

Tanto la naturaleza como el riesgo se relacionan con la intención del cambio, que se conoce al principio del desarrollo:

  • Naturaleza: ¿Va a agregar nuevas características, actualizar las existentes o corregir errores?

  • Riesgo: ¿El cambio afecta a los componentes críticos, como las API o introduce cambios importantes?

La mayoría de los equipos usan versionado semántico (SemVer) para transmitir esta información. SemVer se adopta ampliamente y es eficaz para señalar la naturaleza y el riesgo.

1.2.3
│ │ └─ Patch (bug fixes)
│ └── Minor (new features)
└──── Major (breaking changes)

Calidad del cambio

La calidad del cambio no se conoce por lo general hasta que el proceso de validación se complete. Esto se determina después de la validación, una vez compilado y probado el paquete. Debido a esto, no es factible comunicar la calidad del cambio en el segmento numérico del número de versión (por ejemplo, 1.2.3).

Aunque existen soluciones alternativas para validar previamente (por ejemplo, consumir los archivos DLL de la compilación directamente antes de empaquetarlos y publicarlos en un entorno de "depuración" o "CI", luego validar y volver a publicar esos paquetes en un entorno de "versión"), no garantizan que el paquete final cumpla los estándares de calidad.

Diagrama que muestra un flujo de trabajo de versión de paquete con fases para realizar cambios, compilar, empaquetar, validar y publicar, con llamadas que muestran cuándo se determina la versión y la calidad del paquete.

En su lugar, puedes utilizar las vistas de feed para comunicar la calidad. Con la @Release vista, solo puede compartir paquetes que hayan superado la validación y cumplan la barra de calidad. Esto permite a los consumidores ver solo el subconjunto de versiones de paquete probadas, validadas y listas para consumirse. Este enfoque garantiza que los consumidores accedan a paquetes estables y listos para producción. Consulte Publicar paquetes y administrar vistas del Feed para obtener más detalles.

Contenido relacionado

  • Last updated on