¿Qué es Azure Artifacts?
En esta unidad, verá una breve introducción sobre el uso de Azure Artifacts para crear y administrar de forma segura paquetes que las aplicaciones pueden consumir.
Vamos a volver a consultar con el equipo, ya que es el responsable de decidir si Azure Artifacts es la forma adecuada de hospedar el paquete de .NET.
Mara: me parece que tendría sentido que hospedáramos el paquete Modelos nuevo en Azure Artifacts. Todos formamos parte ya de la organización de Microsoft Azure DevOps, así que sería más fácil autenticarse que intentar configurarlo en otro administrador de paquetes.
Andy: Lo he estado mirando antes de la reunión y me parece que es sencillo. Estoy de acuerdo con Mara.
Amita: ¿Qué es Azure Artifacts?
Andy: Azure Artifacts es un repositorio de la organización de Azure DevOps en el que se pueden administrar las dependencias para el código base. Azure Artifacts puede almacenar los artefactos y los archivos binarios. Proporciona un contenedor, denominado fuente, para los grupos de dependencias. Los desarrolladores que tienen acceso a la fuente pueden consumir o publicar paquetes fácilmente.
¿Cómo se puede crear un paquete y usarlo en la canalización?
Tim: Entonces, si lo he entendido bien, el código de la aplicación ya usa los paquetes de NuGet. Vamos a crear nuestro propio paquete y hospedarlo en Azure Artifacts. ¿Puedes explicarlo por partes? Me está costando imaginarme todo el proceso.
Andy: Claro que sí. Vamos a explicar el proceso de creación de un paquete y en nuestra canalización de Azure DevOps.
Andy va a la pizarra.
Creación del paquete
En primer lugar, tenemos que crear un proyecto en Azure Artifacts. 
Podemos hacer esto desde Azure DevOps.
Después, creamos una canalización en Azure Pipelines que se conecte al repositorio de GitHub para el código de paquete. Luego, la canalización compila el código, lo empaqueta e inserta el paquete en Azure Artifacts. 
Tenemos que actualizar la aplicación que consume este paquete para que apunte a la fuente de Azure Artifacts que hemos creado. 
Después, actualizamos la canalización que crea la aplicación. Esto nos permite usar nuestra fuente de Azure Artifacts para incorporar los cambios en la nueva dependencia del paquete y compilarlo con normalidad. 
Actualización del paquete
Tim: ¿Qué ocurre si alguien actualiza el paquete?
Andy: al actualizar el paquete con una nueva característica o corrección de errores, y ejecutar pruebas para asegurarse de que funciona correctamente, se aumenta el número de versión del paquete. Luego, confirmas el cambio. La canalización del paquete ve la confirmación y crea un artefacto en Azure Artifacts con el número de versión nuevo. No te preocupes, el paquete anterior con el número de versión anterior todavía se mantiene para las aplicaciones que dependen de esa versión. Por eso normalmente no quita de la lista a un paquete.
Es posible que nuestra aplicación quiera usar esta versión más reciente del paquete. En ese caso, se actualiza la aplicación para que haga referencia a la versión más reciente y se ejecutan las pruebas localmente para asegurarse de que esta versión nueva funciona con nuestra aplicación. Cuando estemos seguros de que todo funciona, enviaremos el cambio de la aplicación a la canalización. Se compila con la versión nueva de la dependencia de paquete.
Amita: Parece un buen plan y también ayudará al otro equipo. También evitará desfases en el código cuando se coloque. También ayudará al control de calidad.
Inclusión de una estrategia de control de versiones en la canalización de compilación
Cuando se usa una canalización de compilación, los paquetes necesitan versiones de antes de que se puedan usar y probar. Pero solo se puede conocer la calidad del paquete después de probarlo. Dado que las versiones de los paquetes no se deben cambiar nunca, es difícil elegir una versión determinada de antemano.
Azure Artifacts asocia un nivel de calidad a cada paquete en sus fuentes y distingue entre versiones preliminares y versiones de lanzamiento. Azure Artifacts ofrece diferentes vistas en la lista de paquetes y sus versiones, que los separan en función de su nivel de calidad. Este enfoque funciona bien con el control de versiones semántico, lo que resulta útil para predecir la intención de una versión determinada. Azure Artifacts también usa un descriptor para incluir metadatos adicionales de la fuente de Azure Artifacts. Un uso común de las vistas es compartir versiones de paquetes que se han probado, validado o implementado, pero que mantienen los paquetes en desarrollo y sin que estén listos para el consumo público.
Las fuentes en Azure Artifacts tienen tres vistas diferentes de manera predeterminada. Estas vistas se agregan en el momento en que se crea una fuente. Las tres vistas son las siguientes:
- Versión: la vista @release incluye todos los paquetes que se consideran versiones oficiales.
- Versión preliminar: la vista @prerelease incluye todos los paquetes que tienen una etiqueta en su número de versión.
- Local: la vista @local incluye todos los paquetes de versiones de lanzamiento y preliminares y los paquetes descargados de orígenes ascendentes.
Puede utilizar las vistas para ayudar a los consumidores de una fuente de paquetes a filtrar entre versiones de paquetes publicadas y no publicadas. Básicamente, las vistas permiten a un consumidor elegir de forma consciente entre paquetes publicados o participar en versiones preliminares de un nivel de calidad determinado.
Seguridad de paquetes en Azure Artifacts
Garantizar la seguridad de los paquetes es tan importante como garantizar la seguridad del resto del código. Uno de los aspectos de la seguridad de los paquetes es la protección del acceso a las fuentes de paquetes (en la que una fuente, en Azure Artifacts, es donde se almacenan los paquetes). Establecer permisos en la fuente permite compartir los paquetes con tantas personas como requiera el escenario, independientemente del número.
Permisos de fuente
Las fuentes tienen cuatro niveles de acceso: Propietarios, Contribuidores, Colaboradores y Lectores. Cada nivel de acceso tiene un determinado conjunto de permisos. Por ejemplo, los propietarios pueden agregar cualquier tipo de identidad (usuarios, equipos y grupos) a cualquier nivel de acceso. De manera predeterminada, el Servicio de compilación de la colección de proyectos es un contribuidor y el equipo del proyecto es un lector.
Configuración de la canalización para acceder a la seguridad y la clasificación de licencias
Hay varias herramientas disponibles de terceros para permitirle evaluar la seguridad y la clasificación de licencias de los paquetes de software que se usan.
Algunas de estas herramientas examinan los paquetes tal y como están incluidos en la compilación o la canalización de implementación continua. Durante el proceso de compilación, la herramienta examina los paquetes y proporciona comentarios instantáneos. Durante el proceso de implementación continua, la herramienta utiliza los artefactos de compilación y realiza exámenes. Dos ejemplos de estas herramientas son Mend Bolt y Black Duck. Con Azure DevOps, se usan las tareas de compilación para incorporar el examen en la canalización.