Ejercicio: Creación de una solicitud de incorporación de cambios

12 minutos

En esta unidad practicará el proceso de envío de una solicitud de incorporación de cambios y la combinación de los cambios en la rama main para que todos se puedan beneficiar de su trabajo.

En Creación de una canalización de compilación con Azure Pipelines ha creado una rama de Git denominada build-pipeline donde ha definido una canalización de compilación básica para el sitio web Space Game. Recuerde que la definición de compilación se incluye en un archivo denominado azure-pipelines.yml.

Aunque la rama genera un artefacto de compilación, ese trabajo solo existe en la rama build-pipeline. Tendrá que combinar la rama en la rama main.

Recuerde que una solicitud de incorporación de cambios indica a otros desarrolladores que tiene código listo para revisar si es necesario y que quiere que los cambios se combinen en otra rama como la rama main.

Antes de empezar, volvamos con Mara y Andy.

Andy: Hola, Mara. Sé que tienes una canalización de compilación que se ejecuta en Azure. Voy a agregar una característica al sitio web y me gustaría ver en persona el proceso de compilación. ¿Eso se puede hacer?

Mara: Por supuesto. He creado la canalización en una rama. ¿Por qué no creamos una solicitud de incorporación de cambios y la combinamos en main para que tú también puedas usar la canalización?

Andy: Me parece estupendo. Vamos a echar un vistazo.

Crear una rama y agregar código de inicio

Aunque podría usar la canalización de compilación que creó en el módulo anterior, vamos a crear una rama nueva denominada code-workflow. Esta rama se basa en main, por lo que puede practicar el proceso desde el principio.

En Visual Studio Code, abra el terminal integrado.
Cambie a la rama main:
```
git checkout main
```
Asegúrese de que tiene la versión más reciente del código de GitHub:
```
git pull origin main
```
Cree una rama con el nombre code-workflow:
```
git checkout -B code-workflow
```
El argumento -b especifica que se va a crear una rama si no existe. Omita el argumento -b cuando quiera cambiar a una rama existente.

De forma predeterminada, la nueva rama se basa en la rama anterior desde la que ha ejecutado el comando git checkout. Aquí la rama primaria es main, pero la rama primaria puede ser otra, como una rama de características que haya iniciado otro usuario y que quiera ampliar o con la que quiera experimentar.

Ahora puede realizar con seguridad todos los cambios que necesite, ya que se encuentra en su propia rama local. Si quiere ver en qué rama se encuentra, ejecute git branch -v.

En el explorador de archivos, abra azure-pipelines.yml y reemplace el contenido por el siguiente:

trigger:
- '*'

pool:
  vmImage: 'ubuntu-20.04'
  demands:
  - npm

variables:
  buildConfiguration: 'Release'
  wwwrootDir: 'Tailspin.SpaceGame.Web/wwwroot'
  dotnetSdkVersion: '6.x'

steps:
- task: UseDotNet@2
  displayName: 'Use .NET SDK $(dotnetSdkVersion)'
  inputs:
    version: '$(dotnetSdkVersion)'

- task: Npm@1
  displayName: 'Run npm install'
  inputs:
    verbose: false

- script: './node_modules/.bin/node-sass $(wwwrootDir) --output $(wwwrootDir)'
  displayName: 'Compile Sass assets'

- task: gulp@1
  displayName: 'Run gulp tasks'

- script: 'echo "$(Build.DefinitionName), $(Build.BuildId), $(Build.BuildNumber)" > buildinfo.txt'
  displayName: 'Write build info'
  workingDirectory: $(wwwrootDir)

- task: DotNetCoreCLI@2
  displayName: 'Restore project dependencies'
  inputs:
    command: 'restore'
    projects: '**/*.csproj'

- task: DotNetCoreCLI@2
  displayName: 'Build the project - $(buildConfiguration)'
  inputs:
    command: 'build'
    arguments: '--no-restore --configuration $(buildConfiguration)'
    projects: '**/*.csproj'

- task: DotNetCoreCLI@2
  displayName: 'Publish the project - $(buildConfiguration)'
  inputs:
    command: 'publish'
    projects: '**/*.csproj'
    publishWebProjects: false
    arguments: '--no-build --configuration $(buildConfiguration) --output $(Build.ArtifactStagingDirectory)/$(buildConfiguration)'
    zipAfterPublish: true

- task: PublishBuildArtifacts@1
  displayName: 'Publish Artifact: drop'
  condition: succeeded()

Esta configuración es similar a la básica que ha creado en el módulo anterior. Por motivos de brevedad, solo compila la configuración de lanzamiento del proyecto.

Inserción de la rama en GitHub

Aquí, inserte la rama code-workflow en GitHub y vea cómo Azure Pipelines compila la aplicación.

En el terminal, ejecute git status para ver qué trabajo no confirmado hay en la rama:
```
git status
```
Verá que azure-pipelines.yml se ha modificado. Lo confirmará en la rama en breve, pero primero debe asegurarse de que Git está realizando el seguimiento de este archivo, lo que se denomina almacenamiento provisional del archivo.

Solo se confirman los cambios almacenados provisionalmente al ejecutar git commit. Después, ejecute el comando git add para agregar azure-pipelines.yml al área de almacenamiento provisional o al índice.
Ejecute el siguiente comando git add para agregar azure-pipelines.yml al área de almacenamiento provisional:
```
git add azure-pipelines.yml
```
Ejecute el comando git commit siguiente para confirmar en la rama code-workflow el archivo almacenado provisionalmente:
```
git commit -m "Add the build configuration"
```
El argumento -mespecifica el mensaje de confirmación. El mensaje de confirmación se convierte en parte del historial de un archivo modificado. Ayuda a los revisores a comprender el cambio, y a los futuros mantenedores a entender cómo ha cambiado el archivo en el tiempo.

Sugerencia

Los mejores mensajes de confirmación completan la frase "Si aplica esta confirmación, podrá..."

Si se omite el argumento -m, Git abre un editor de texto donde puede detallar el cambio. Esta opción es útil cuando se quiere especificar un mensaje de confirmación que abarca varias líneas. El texto hasta la primera línea en blanco especifica el título de la confirmación.
Ejecute este comando git push para insertar, o cargar, la rama code-workflow en el repositorio de GitHub:
```
git push origin code-workflow
```
Como paso opcional, vaya a su proyecto en Azure Pipelines y realice un seguimiento de la compilación a medida que se ejecuta.

Esta compilación se denomina compilación de CI. La configuración de la canalización usa lo que se denomina un desencadenador para controlar qué ramas participan en el proceso de compilación. Aquí, "*" especifica todas las ramas.
```
trigger:
- '*'
```
Más adelante, verá cómo controlar la configuración de la canalización para efectuar la compilación solo a partir de las ramas que necesite.

Verá que la compilación se completa correctamente y genera un artefacto que contiene la aplicación web compilada.

Crear una solicitud de incorporación de cambios

Aquí creará una solicitud de incorporación de cambios para la rama:

En un explorador, inicie sesión en GitHub.
Vaya al repositorio mslearn-tailspin-spacegame-web.
En la lista desplegable Rama, seleccione la rama code-workflow.
Para iniciar la solicitud de incorporación de cambios (“pull request”), seleccione Contribuir y, a continuación, Open pull request (Abrir “pull request”).
Asegúrese de que en base se especifica el repositorio bifurcado y no el de Microsoft.

Su selección tiene este aspecto:

Importante

Este paso es importante porque no se pueden combinar los cambios en el repositorio de Microsoft. Garantice que el repositorio base apunta a su cuenta de GitHub y no a MicrosoftDocs.

Si termina con una solicitud de incorporación de cambios en MicrosoftDocs, basta con cerrar la solicitud y repetir estos pasos.

Este proceso implica un paso adicional porque está trabajando desde un repositorio bifurcado. Cuando trabaje directamente con un repositorio propio y no una bifurcación, la rama main se selecciona de forma predeterminada.
Escriba un título y una descripción para la solicitud de incorporación de cambios.
- Título:
  
  Configuración de Azure Pipelines
- Descripción:
  
  Esta configuración de canalización compila la aplicación y genera una compilación para la configuración de lanzamiento.
Para completar la solicitud de incorporación de cambios, seleccione el botón Crear solicitud de incorporación de cambios.

En este paso no se combina ningún código. Indica a otros usuarios que ha propuesto que los cambios se combinen en la rama main.

Se muestra la ventana de la solicitud de incorporación de cambios. También verá que el estado de la compilación en Azure Pipelines está configurado para que aparezca como parte de la solicitud de incorporación de cambios. De este modo, usted y otros usuarios pueden ver el estado de la compilación a medida que se ejecuta.

Al igual que cuando se inserta una rama en GitHub, de forma predeterminada una solicitud de incorporación de cambios desencadena Microsoft Azure Pipelines para compilar la aplicación.

Sugerencia

Si no ve el estado de compilación de inmediato, espere unos minutos o actualice la página.
Opcionalmente, seleccione el vínculo Detalles y, después, haga el seguimiento de la compilación mientras se desplaza a través de la canalización.

Puede entregar la compilación al paso siguiente del proceso, por ejemplo al control de calidad. Posteriormente, puede configurar la canalización para insertar el cambio directamente en el laboratorio de control de calidad o de producción.
Vuelva a la solicitud de incorporación de cambios en GitHub.

Espere a que la compilación finalice. Ya está listo para combinar la solicitud de incorporación de cambios.
Seleccione Merge pull request (Fusionar solicitud de incorporación de cambios) y, después, Confirm merge (Confirmar fusión).
Para eliminar la rama code-workflow de GitHub, seleccione Eliminar rama.

Una vez que se ha combinado la solicitud de incorporación de cambios, se puede eliminar con total seguridad una rama de GitHub. De hecho, es un procedimiento habitual porque la rama ya no es necesaria. Los cambios se han combinado y todavía puede encontrar detalles sobre los cambios en GitHub o desde la línea de comandos. La eliminación de una rama combinada también ayuda a otros usuarios a ver solo el trabajo que está activo actualmente.

Las ramas de Git están diseñadas para ser de corta duración. Después de combinar una rama, no se insertan confirmaciones adicionales en ella ni se combina una segunda vez. En la mayoría de los casos, cada vez que se comienza una característica o corrección de errores nueva, se empieza con una rama limpia basada en la rama main.

La eliminación de una rama en GitHub no la elimina del sistema local. Para hacerlo, tendría que pasar el modificador -d al comando git branch.

¿Cuántas veces se compila un cambio?

La respuesta depende de cómo se defina la configuración de compilación. Azure Pipelines permite definir desencadenadores que especifican qué eventos provocan que se produzca una compilación. Puede controlar qué ramas se compilan o incluso qué archivos desencadenan la compilación.

Por ejemplo, supongamos que quiere que se produzca una compilación cuando se inserte un cambio en GitHub en cualquier rama de Git. Pero no quiere que la compilación se produzca cuando solo se modifican los archivos de la carpeta docs del proyecto. Podría interesarle incluir esta sección trigger en la configuración de compilación:

trigger:
  branches:
    include:
    - '*'     # build all branches
  paths:
    exclude:
    - docs/*  # exclude the docs folder

De forma predeterminada, una compilación se desencadena cuando se inserta un cambio en cualquier archivo de cualquier rama.

Una compilación de integración continua (CI) es la que se ejecuta cuando se inserta un cambio en una rama.

Una compilación de solicitud de incorporación de cambios (PR) es la que se ejecuta al abrir una solicitud de incorporación de cambios o cuando se insertan cambios adicionales en una solicitud de incorporación de cambios existente.

Los cambios que haga en la rama code-workflow se compilan en función de tres condiciones:

Se produce una compilación de CI cuando los cambios se insertan en la rama code-workflow.
Se produce una compilación de PR al abrir una solicitud de incorporación de cambios en la rama code-workflow sobre la rama main.
Se produce una compilación de CI final después de combinar la solicitud de incorporación de cambios en la rama main.

Las compilaciones de PR ayudan a comprobar que los cambios propuestos van a funcionar correctamente después de combinarlos en main o en otra rama de destino.

La compilación de CI final comprueba que los cambios siguen siendo correctos después de que se haya combinado la solicitud de incorporación de cambios.

Como paso opcional, vaya a Azure Pipelines y observe cómo se realiza la última compilación de CI en la rama main.

Continuar

Ejercicio: Creación de una solicitud de incorporación de cambios

Crear una rama y agregar código de inicio

Inserción de la rama en GitHub

Crear una solicitud de incorporación de cambios

¿Cuántas veces se compila un cambio?

Comentarios