Exercice : Promouvoir vers la phase de développement

8 minutes

L’équipe dispose d’un plan et est prête à commencer à implémenter son pipeline de mise en production. Votre projet Azure DevOps est configuré et vos instances Azure App Service sont prêtes à recevoir des artefacts de build.

À ce stade, n’oubliez pas que le pipeline de l’équipe ne comporte que deux phases. La première phase produit l’artefact de build. La deuxième étape déploie l’application web Space Game sur App Service. Ici, vous suivez Andy et Mara pendant qu’ils modifient la chaîne de traitement. Ils vont être déployés dans l’environnement App Service qui correspond à la phase de développement .

Ici, vous utilisez un déclencheur CI pour démarrer le processus de génération.

Récupérer (fetch) la branche à partir de GitHub

Ici, vous récupérez la release branche depuis GitHub. Vous basculez également vers la branche.

Cette branche fait office de branche de mise en production. Il contient le projet Space Game utilisé dans les modules précédents. Elle contient également une configuration Azure Pipelines pour commencer.

Pour récupérer et basculer vers la branche :

Dans Visual Studio Code, ouvrez le terminal intégré.
Pour extraire une branche nommée release à partir du référentiel Microsoft et basculer vers cette branche, exécutez les commandes suivantes git .
```
git fetch upstream release
git checkout -B release upstream/release
```
Le format de ces commandes vous permet d’obtenir du code de démarrage à partir du dépôt Microsoft GitHub, appelé upstream. Sous peu, vous allez pousser cette branche vers le haut vers votre dépôt GitHub, appelé origin.
En guise d’étape facultative, à partir de Visual Studio Code, ouvrez azure-pipelines.yml. Familiarisez-vous avec la configuration initiale.

Remarque

Pour une configuration plus robuste, les branches qui participent au processus de génération pourraient être spécifiées. Par exemple, pour faciliter la vérification de la qualité du code, vous pouvez effectuer des tests unitaires chaque fois que vous poussez une modification dans une branche. Vous pouvez aussi déployer l’application sur un environnement qui effectue des tests plus exhaustifs. Toutefois, vous ne procédez à ce déploiement que lorsque vous avez une pull request, lorsque vous disposez d'une release candidate, ou lorsque vous fusionnez du code sur la branche main.

Pour plus d’informations, consultez Implémenter un workflow de code dans votre pipeline de build à l’aide de Git et GitHub et Déclencheurs de pipeline de build.

Promouvoir les modifications apportées à la phase de développement

Ici, vous modifiez votre configuration de pipeline pour promouvoir la compilation à l'étape Dev.

Dans Visual Studio Code, modifiez azure-pipelines.yml.

trigger:
- '*'

variables:
  buildConfiguration: 'Release'
  releaseBranchName: 'release'

stages:
- stage: 'Build'
  displayName: 'Build the web application'
  jobs: 
  - job: 'Build'
    displayName: 'Build job'
    pool:
      vmImage: 'ubuntu-20.04'
      demands:
      - npm

    variables:
      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

    - publish: '$(Build.ArtifactStagingDirectory)'
      artifact: drop

- stage: 'Dev'
  displayName: 'Deploy to the dev environment'
  dependsOn: Build
  condition: |
    and
    (
      succeeded(),
      eq(variables['Build.SourceBranchName'], variables['releaseBranchName'])
    )
  jobs:
  - deployment: Deploy
    pool:
      vmImage: 'ubuntu-20.04'
    environment: dev
    variables:
    - group: Release
    strategy:
      runOnce:
        deploy:
          steps:
          - download: current
            artifact: drop
          - task: AzureWebApp@1
            displayName: 'Azure App Service Deploy: website'
            inputs:
              azureSubscription: 'Resource Manager - Tailspin - Space Game'
              appName: '$(WebAppNameDev)'
              package: '$(Pipeline.Workspace)/drop/$(buildConfiguration)/*.zip'

Cette configuration ressemble à celle que vous avez créée dans le module précédent. Là, vous et l’équipe avez créé une preuve de concept pour le déploiement continu. Notez toutefois ces différences, qui sont mises en surbrillance dans l’exemple de code précédent :

Cette configuration définit des variables au début du fichier. Les variables sont utilisées dans tout le pipeline. Ils définissent la configuration à générer (Release). Ils définissent également le nom de votre branche de mise en production (release).
La phase de déploiement à partir de la preuve de concept est maintenant nommée Dev.
La phase de développement utilise une condition qui dirige le système pour exécuter la phase uniquement lorsque l’étape précédente réussit et que la branche actuelle est release. Cette configuration garantit que les fonctionnalités de mise en production sont déployées uniquement dans l’environnement de développement .
L’étape de déploiement utilise la variable WebAppNameDev pour déployer sur l’instance App Service associée à l’environnement Dev.

Remarque

Dans la pratique, vous pouvez effectuer le déploiement à partir d’une autre branche telle que main. Vous pouvez inclure une logique qui permet de promouvoir les modifications à l’étape de développement à partir de plusieurs branches, telles que release et main.

À partir du terminal intégré, ajoutez azure-pipelines.yml à l’index. Validez la modification et envoyez-la à GitHub.

Conseil / Astuce

Avant d’exécuter ces commandes Git, enregistrez azure-pipelines.yml.
```
git add azure-pipelines.yml
git commit -m "Deploy to the Dev stage"
git push origin release
```
Dans Azure Pipelines, accédez à la build. Suivez l’exécution de la build.
Une fois la construction terminée, pour revenir à la page récapitulative, sélectionnez le bouton précédent.

Vous voyez que le déploiement s’est terminé correctement.
À partir d’un navigateur web, accédez à l’URL associée à l’instance App Service pour votre environnement de développement .

Si l’onglet du navigateur est toujours ouvert, actualisez la page. Si vous ne vous souvenez pas de l’URL, recherchez-la dans le portail Azure, dans la page de détails d’App Service .

Vous voyez que le site web Space Game est déployé sur App Service et est en cours d’exécution.
En guise d’étape facultative, dans Azure Pipelines, sélectionnez Environnements. Sélectionnez ensuite l’environnement de développement .

Azure Pipelines enregistre votre historique de déploiement. Dans l’historique, vous pouvez retracer les changements de l’environnement jusqu’aux validations de code et aux éléments de travail.

Commentaires

Cette page a-t-elle été utile ?