Configuración de una canalización de compilación en Azure DevOps para una API de ASP.NET Core (2023)

30 de octubre de 2018

João Grassi— un desarrollador de .NET, aficionado al front-end y amigo de Sentry — le gusta mucho .NET y recientemente trató de llevar a un amigo al "lado oscuro" del desarrollo de .NET. Para ganar un punto, decidió crear un pequeño proyecto de muestra con Azure DevOps.

Cuando comenzó, luchó por encontrar información útil en la documentación (como cómo controlar el nombre del artefacto). Cuando terminó el proyecto, se preguntó: ¿No sería bueno tener esto en algún lugar para evitar la molestia de buscar todo en Google nuevamente?

No hay duda de que el desarrollo en la nube se está volviendo cada vez más popular y, para muchos, es la forma de facto de crear, implementar y alojar aplicaciones en la web. Pero muchos de nosotros aún trabajamos en nuestro trabajo diario en un entorno sin nubes debido a razones que no son relevantes para esta publicación.

Realmente no hay excusa cuando se trata de evitar el desarrollo en la nube y aprovechar todas las cosas buenas que puede obtener de él. Un beneficio específico es la capacidad de configurar una canalización de compilación que compila el proyecto, garantiza que todo se esté compilando y verifica que las pruebas estén pasando. Las canalizaciones de compilación también producen artefactos, o archivos .zip que contienen el código de su aplicación, que le permiten publicar su aplicación en Azure u otros servicios en la nube.

What we are going to do

En esta publicación, quiero mostrarte cómo:

1. Cree un servicio de aplicaciones en Linux en Azure.
2. Configure una canalización de compilación en Azure DevOps (anteriormente conocido como VSTS).
3. Integre Azure DevOps con Sentry.

algunos requisitos

Para evitar que esta publicación sea demasiado larga, asumiré que ya tiene la siguiente configuración:

• An account on Azure DevOps within an organization: Solo sigue los pasos aquí.
• A git repo on Azure DevOps for your project: aquíyhere.
• The actual code — An ASP.NET Core API up and running (the simplest initial template (ValuesController), either via VS or command line).

Al final, debe tener su repositorio git configurado localmente y en Azure DevOps para que pueda empujar/tirar cosas. El menú "Repos" en Azure DevOps se ve así:

Creating the App Service on Azure

Tampoco voy a entrar en demasiados detalles sobre cómo crear App Service en Azure, principalmente porque ya estabaexplicado mejor antes, pero quiero mostrárselo brevemente a través de Azure Portal. Entonces vamos:

1. Log into your Azure portal (after creating your free account).
2. Ir a:App Services → Agregar (+) → Aplicación web → Crear

3. Rellene todos los campos, como se ve aquí:

4. ¡Presiona Crear!

Creación de la compilación en Azure DevOps

Now that you have your git repo and your App Service created, it’s time to configure the build pipeline on Azure DevOps. It’s very easy and well integrated with ASP.NET Core, so we’ll use most of the pre-defined values:

1. Navigate to: Tuberías → + Nuevo → Tubería de nueva construcción.
2. En la página siguiente, debe seleccionar el origen de la compilación, que en nuestro caso es Azure Repos Git. Pero como puede ver, puede conectarse a otros proveedores de Git como GitHub. Seleccione su proyecto y repositorio (probablemente ya esté preseleccionado) y presioneContinuar.

3. On the “Select a template” page, select Núcleo de ASP.NET and hit Aplicar(también puedes buscarlo).
4. La página siguiente es donde configuraremos los pasos de compilación. Dado que seleccionamos la plantilla de ASP.NET Core, Azure DevOps ya nos brinda un conjunto de pasos predefinidos. Experimenté con ellos un poco y se me ocurrieron mis propios cambios. Voy a explicar cada paso ahora:

Pipeline - Build pipeline

La primera "caja" es la que está en la parte superior de todo:Pipeline. There, you can set up the name of the build pipeline, on which agent it runs and the projects to build/restore. Fill in the Build name and Agent “Hosted VS2017”. Leave the rest as it is, we will change them later:

Restore

No tenemos que hacer una restauración desde .NET Core 2.0, pero, en compilaciones de CI como esta, es bueno tenerlo separado porque podemos medir cuánto tiempo llevó cada paso.

Asegúrese de seleccionar la versión 2 de .NET Core.* Lo único que vamos a cambiar aquí es la Ruta a los proyectos. Por defecto intenta restaurar todos los proyectos. En nuestra API simple, solo necesitamos restaurar el proyecto Api.

1. En elRuta a proyecto(s) field, click on the enlace icon next to it and then on Unlink. This will enable us to change the field.
2. Change it to the path of your main API .csprojarchivo. En mi caso es:**/StarWars.Api.csproj

Ahora realiza una restauración para el proyecto API, y si la API tiene dependencias con otros proyectos en la solución, también restaurará para esos.

Build

En elConstruirpaso vamos a cambiar 3 cosas: elRuta a proyecto(s), the Argumentosy elWorking Directory.

1. Click again in the link icon next to Path to project(s) and point it to the .csprojde su API nuevamente como en el paso de restauración.
2. In the Arguments step add a --no-restore flag to avoid construir dotnethaciendo una restauración de nuevo:--configuration $(BuildConfiguration) --no-restore
3. Expand the Avanzado menu and add the folder of your API project to the Directorio de trabajo. En mi caso, esto:src/StarWars.Api

I always use this format for my projects (and I believe most projects out there also use it):

No es necesario que tenga esta estructura, pero creo que funciona bien y está bien organizada. Por ejemplo, me gusta colocar todos mis proyectos de prueba en una carpeta de prueba en la misma jerarquía que la carpeta src.

Prueba

En elPruebapaso, especifico los proyectos que quiero probar. Una gran solución a menudo tiene múltiples proyectos, y probablemente también tenga compilaciones separadas para cada uno de ellos. En este caso, tiene más sentido especificar cada proyecto de prueba para ejecutar.

Publicar

ElPublicarpaso fue donde me quedé atrapado la primera vez que intenté configurar mi canalización de compilación. Puede usar prácticamente los valores predeterminados, y funcionará bien. El problema es que publica los artefactos con nombres muy raros. Por ejemplo:

No pude encontrar un mejor nombre de artefacto usando las opciones predeterminadas. Los nombres de los artefactos deben ser significativos e incluir información como el número de compilación. Eventualmente usé estos pasos para cambiar el nombre del artefacto:

1. Desmarque laPublicar proyectos webcasilla de verificación y agregue nuevamente la ruta al proyecto API:**/StarWars.Api.csproj
2. En elArgumentospega esto:-c $(BuildConfiguration) -o $(Build.StagingDirectory)/ci-build --no-build

El-Ccomando le dirá a Azure DevOps que use elConfiguración de compilaciónvariable. De forma predeterminada, la variable se establece enliberar, pero puedes cambiarlo enVariablespestaña en esta página.

El-oEl argumento especifica la ubicación de la salida de publicación. En mi ejemplo, lo especifiqué para publicar en el predefinidoBuild.StagingDirectorydisponible en Azure DevOps plus en elci-construircarpeta. Si no especifica elci-construircarpeta, creará una carpeta para ella.

Y, por supuesto, dado que ya hemos construido el proyecto, no es necesario volver a hacerlo. Entonces, sáltate el--no-construir.

3. También desmarqué laZip Proyectos PublicadosyAgregue el nombre del proyecto a la ruta de publicación. Crearemos nuestro propio zip en el siguiente paso.
4. Ampliar de nuevo laAvanzadomenú y configurar elCarpeta de trabajode nuevo como hicimos en elConstruirpaso.

Estos pasos deberían resultar en algo como esto:

Archivar la salida de publicación

Ahora que tenemos los resultados de nuestropublicar dotnetcomando, necesitamos archivarlo.

1. Clickea en el+ botóncercaFase 1.
2. Selecciona elArchivar archivosopción. Puede buscarlo si no está visible.
3. Elija un nombre para el paso, por ejemplo,Archivo Publicar Salida.
4. En elCarpeta raízoarchivo para archivaragregar la ruta a lapublicararchivos de salida configurados antes:$(Build.StagingDirectory)/ci-build
5. No quiero anteponer el nombre de la carpeta raíz en el zip, ya que me gustaría que mis archivos estén en la raíz. Así que desmarqué laAnteponga el nombre de la carpeta raíz a las rutas de archivocaja.
6. En elArchivo de archivoto create es donde configuramos el nombre del artefacto zip. Cambié el mío a:$(Build.ArtifactStagingDirectory)/starwars-api.$(Build.BuildNumber).zip. Asegúrese también de marcar elReemplazar archivo existentepor si acaso.

Este paso toma los archivos producidos a partir de lapublicarpaso disponible en$(Build.StagingDirectory)/ci-buildy los cierra con un nombre compuesto porstarwars-api.buildnumber.zip. usé elBuild.BuildNumbervariable expuesta por Azure DevOps para construir ese nombre. Tenga en cuenta que también codifiqué elstarwars-apiparte, pero también puede establecer una variable para eso, o usar uno de losmuchos predefinidos, como el nombre de compilación, por ejemplo.

El paso de archivo debería verse así:

Publicar artefacto

En este paso, solo seleccionamos el archivo .zip y lo movemos a la carpeta adecuada en Azure DevOps. Dado que cambiamos los valores predeterminados, también debemos cambiar algunos campos aquí para que coincidan con nuestro nuevo nombre/ruta de artefacto:

1. Cambiar elRuta para publicara:$(Build.ArtifactStagingDirectory)/starwars-api.$(Build.BuildNumber).zip. Esto publicará nuestro código postal en esa ubicación.
2. En elArtefactocampo de nombre agregue nuevamente el nombre del artefacto que creamos:starwars-api.$(Build.BuildNumber)
3. Deje el resto con los valores predeterminados.

¡Eso es todo por la parte de construcción! Ahora puedes ir aTuberías → Compilaciones → Cola, espera a que termine y deberías tener un buen artefacto.

Integración de Sentry y Azure DevOps

Ahora que su canalización de compilación está configurada en Azure DevOps, puedeintegrar con centineladesbloquee el seguimiento mejorado de versiones, correos electrónicos de implementación informativos y sugerencias de asignatarios para nuevos errores.

1. En Sentry, navegue hastaConfiguración de la organización → Integraciones. (Nota: solo los usuarios con permisos de propietario y administrador tendrán acceso a esta página).

2. Si tiene instalada la integración VSTS heredada, verá un botón junto a Azure DevOps que diceMejora. Si no tiene instalada la integración VSTS heredada, verá un botón que diceInstalar. Haga clic en este botón.
3. En el modal resultante, haga clic enAgregar instalación.
4. Debería aparecer una ventana de instalación de Azure DevOps. Seleccione la cuenta de Azure DevOps que desea vincular con Sentry y presioneEntregar.

Lea más sobre las características de esta integraciónaquíy aprenda a configurar esas funcionesaquí.

También puede consultar la publicación original de Joao, hacerle ping con sus preguntas y leer sobre sus otras aventuras en .NET ensu blog.