Exercice - Créer une demande de tirage - Training

12 minutes

Dans cette unité, vous expérimentez le processus de soumission d’une requête de tirage et de fusion de vos modifications dans la branche main afin que tout le monde puisse tirer parti de votre travail.

Dans Créer un pipeline de build avec Azure Pipelines, vous avez créé une branche Git nommée build-pipeline, dans laquelle vous avez défini un pipeline de build de base pour le site web Space Game. Rappelez-vous que votre définition de build se trouve dans un fichier nommé azure-pipelines.yml.

Même si votre branche produit un artefact de build, ce travail existe uniquement sur la branche build-pipeline. Vous devez fusionner votre branche dans la branche main.

Rappelez-vous qu’une requête de tirage indique aux autres développeurs que vous avez du code prêt à être révisé, si nécessaire, et que vous souhaitez que vos modifications soient fusionnées dans une autre branche, telle que la branche main.

Avant de commencer, nous allons faire le point avec Mara et Andy.

Andy : Bonjour Mara. Je sais que vous avez un pipeline de build en cours d’exécution sur Azure. Je suis en train d’ajouter une fonctionnalité au site web et je veux voir le processus de génération moi-même. Sommes-nous prêts à le faire ?

Mara : Bien sûr. J’ai créé le pipeline sur une branche. Pourquoi ne pas créer une requête de tirage et la fusionner dans main afin de pouvoir utiliser le pipeline également ?

Andy : Ça a l’air intéressant. Jetons un œil sur cette configuration.

Créer une branche et ajouter un code de démarrage

Vous pourriez utiliser le pipeline de build que vous avez créé dans le module précédent, mais nous allons plutôt créer une branche nommée code-workflow. Cette branche étant basée sur la branche main, vous pouvez effectuer le processus du début.

Dans Visual Studio Code, ouvrez le terminal intégré.
Passez à la branche main :
```
git checkout main
```
vérifiez que vous disposez de la dernière version du code à partir de GitHub :
```
git pull origin main
```
Créez une branche nommée code-workflow :
```
git checkout -B code-workflow
```
L’argument -b spécifie de créer une branche si elle n’existe pas. Omettez l’argument -b quand vous souhaitez basculer vers une branche existante.

Par défaut, votre nouvelle branche s’appuie sur la branche précédente à partir de laquelle vous avez exécuté la commande git checkout. Dans cette section, la branche parente est main. Toutefois, la branche parente peut être une autre branche, par exemple une branche de caractéristiques créée par quelqu'un d'autre et sur laquelle vous voulez vous appuyer ou avec laquelle vous voulez faire des expériences.

Vous pouvez désormais apporter toutes les modifications nécessaires de manière sécurisée, car vous êtes dans votre propre branche locale. Si vous souhaitez voir la branche sur laquelle vous vous trouvez, exécutez git branch -v.

À partir de l’Explorateur de fichiers, ouvrez azure-pipelines.yml et remplacez son contenu par ceci :

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()

Cette configuration ressemble à la configuration de base que vous avez créée dans le module précédent. Par souci de concision, elle génère uniquement la configuration Release de votre projet.

Pousser votre branche vers GitHub

Dans cette section, vous allez envoyer votre branche code-workflow vers GitHub et regardez Azure Pipelines générer l'application.

Dans le terminal, exécutez git status pour voir le travail non commité qui existe dans votre branche :
```
git status
```
Vous voyez que le fichier azure-pipelines.yml a été modifié. Avant de le commiter dans votre branche, vous devez vous assurer que Git effectue le suivi de ce fichier (ce processus est appelé indexation du fichier).

Seuls les changements indexés sont commités quand vous exécutez git commit. Ensuite, exécutez la commande git add pour ajouter azure-pipelines.yml à la zone d’indexation, ou index.
Exécutez la commande git add suivante pour ajouter azure-pipelines.yml dans la zone de transit :
```
git add azure-pipelines.yml
```
Exécutez la commande git commit suivante pour commiter votre fichier indexé dans la branche code-workflow :
```
git commit -m "Add the build configuration"
```
L’argument -m spécifie le message de commit. Le message de commit devient une partie de l’historique d’un fichier modifié. Cela aide les réviseurs à comprendre la modification, et les futurs chargés de maintenance à comprendre comment le fichier a changé au fil du temps.

Conseil

Les meilleurs messages de commit suivent la phrase « si vous appliquez ce commit, vous allez... »

Si vous omettez l’argument -m, Git affiche un éditeur de texte dans lequel vous pouvez détailler la modification. Cette option est utile quand vous souhaitez spécifier un message de commit qui s’étend sur plusieurs lignes. Le texte jusqu’à la première ligne vide spécifie le titre du commit.
Exécutez cette commande git push pour pousser, ou charger, la branche code-workflow vers votre dépôt sur GitHub :
```
git push origin code-workflow
```
En guise d’étape facultative, accédez à votre projet dans Azure Pipelines et tracez la build à mesure qu’elle s’exécute.

Cette build est appelée build CI. Votre configuration de pipeline utilise ce que l’on appelle un déclencheur pour contrôler les branches qui participent au processus de génération. Ici, « * » désigne toutes les branches.
```
trigger:
- '*'
```
Plus tard, vous verrez comment contrôler votre configuration de pipeline pour effectuer une génération uniquement à partir des branches dont vous avez besoin.

Vous voyez que la génération se déroule correctement et produit un artefact qui contient l’application web générée.

Créer une demande de tirage

Dans cette section, vous créez une requête de tirage (pull) pour votre branche :

Dans un navigateur, connectez-vous à GitHub.
Accédez au dépôt mslearn-tailspin-spacegame-web.
Dans la liste déroulante Branch, sélectionnez votre branche code-workflow.
Pour démarrer votre demande de tirage, sélectionnez Contribute, puis Opein pull request.
Vérifiez que la liste déroulante base spécifie votre dépôt dupliqué et non pas le dépôt Microsoft.

Votre sélection se présente comme suit :

Important

Cette étape est importante, car vous ne pouvez pas fusionner vos modifications dans le dépôt Microsoft. Assurez-vous que le dépôt de base pointe vers votre compte GitHub et non vers MicrosoftDocs.

Si vous obtenez une demande de tirage sur MicrosoftDocs, il vous suffit de la fermer et de répéter ces étapes.

Ce processus implique une étape supplémentaire, car vous travaillez à partir d’un dépôt dupliqué. Quand vous travaillez directement avec votre propre dépôt, et non pas avec une duplication (fork), votre branche main est sélectionnée par défaut.
Entrez un titre et une description pour votre demande de tirage.
- Titre :
  
  Configure Azure Pipelines
- Description :
  
  Cette configuration de pipeline génère l’application et engendre une build pour la configuration Release.
Pour terminer votre demande de tirage, sélectionnez Create pull request.

Cette étape ne fusionne aucun code. Cela indique aux autres personnes que vous avez proposé de fusionner des modifications dans la branche main.

La fenêtre de la demande de tirage s’affiche. Vous pouvez voir que l’état de la build dans Azure Pipelines est configuré pour s’afficher dans le cadre de la demande de tirage. De cette façon, les autres personnes et vous-même pouvez voir l’état de la build au cours de son exécution.

Tout comme quand vous poussez une branche vers GitHub, une demande de tirage, par défaut, déclenche la génération de votre application par Microsoft Azure Pipelines.

Conseil

Si l’état de la build n’apparaît pas immédiatement, patientez quelques instants ou actualisez la page.
Si vous le souhaitez, sélectionnez le lien Details, puis tracez la build au fur et à mesure qu’elle se déplace dans le pipeline.

Vous pouvez transmettre votre build à l’étape suivante du processus, par exemple AQ. Plus tard, vous pourrez configurer le pipeline pour pousser votre changement vers votre labo AQ ou votre environnement de production.
Revenez à votre demande de tirage sur GitHub.

Attendez la fin de la génération. Vous êtes maintenant prêt à fusionner votre demande de tirage.
Sélectionnez Merge pull request, puis Confirm merge.
Pour supprimer la branche code-workflow de GitHub, sélectionnez Delete branch.

Après avoir fusionné votre demande de tirage, vous pouvez supprimer une branche de GitHub de manière sécurisée. De fait, il s’agit d’une pratique courante, car la branche n’est plus nécessaire. Les modifications sont fusionnées et vous pouvez toujours trouver les détails sur les modifications sur GitHub ou à partir de la ligne de commande. La suppression d’une branche fusionnée aide également les autres utilisateurs à voir uniquement le travail actif.

Les branches Git sont destinées à être éphémères. Une fois que vous avez fusionné une branche, vous n’y poussez pas d’autres commits ou ne la fusionnez pas une deuxième fois. Dans la plupart des cas, chaque fois que vous commencez à travailler sur une nouvelle fonctionnalité ou un correctif de bogue, vous démarrez avec une branche vierge qui est basée sur la branche main.

La suppression d’une branche sur GitHub ne supprime pas cette branche de votre système local. Pour ce faire, vous devez passer le commutateur -d à la commande git branch.

Combien de fois une modification est-elle générée ?

La réponse dépend de la définition de votre configuration de build. Azure Pipelines vous permet de définir des déclencheurs qui spécifient les événements entraînant des générations. Vous pouvez contrôler les branches qui sont générées ou même les fichiers qui déclenchent la génération.

Par exemple, supposons que vous souhaitiez qu’une génération se produise quand une modification est poussée vers GitHub sur une branche Git. Toutefois, vous ne souhaitez pas que la génération se produise quand les modifications ne concernent que les fichiers se trouvant dans le dossier docs de votre projet. Si vous le souhaitez, incluez cette section trigger dans votre configuration de build :

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

Par défaut, une génération est déclenchée quand une modification est envoyée vers un fichier sur une branche quelconque.

Une build CI (intégration continue) est une build qui s’exécute quand vous poussez une modification vers une branche.

Une build PR (requête de tirage) est une build qui s’exécute quand vous ouvrez une demande de tirage ou que vous poussez des modifications supplémentaires vers une demande de tirage existante.

Les modifications que vous effectuez dans la branche code-workflow sont générées dans les trois conditions suivantes :

Une build CI se produit quand vous poussez des modifications vers la branche code-workflow.
Une build PR se produit quand vous ouvrez une demande de tirage sur la branche code-workflow par rapport à la branche main.
Une build CI finale se produit après la fusion de la requête de tirage dans la branche main.

Les builds PR vous aident à vérifier que vos modifications proposées fonctionneront correctement une fois qu’elles auront été fusionnées dans main ou une autre branche cible.

La build CI finale vérifie que les modifications sont toujours correctes une fois que la demande de tirage a été fusionnée.

En guise d’étape facultative, accédez à Azure Pipelines et observez la build CI finale sur la branche main.

Continuer

Exercice - Créer une demande de tirage

Créer une branche et ajouter un code de démarrage

Pousser votre branche vers GitHub

Créer une demande de tirage

Combien de fois une modification est-elle générée ?

Commentaires