Exercice - Promouvoir vers la phase de développement
L’équipe a un plan et est prête à commencer à implémenter son pipeline de mise en production. Votre projet Azure DevOps est configuré et vos instances d’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 phase déploie l’application web Space Game sur App Service. Dans le cadre de cet exercice, vous allez suivre Andy et Mara dans leur travail de modification du pipeline. Ils vont effectuer un déploiement dans l’environnement App Service qui correspond à la phase de Développement.
La phase de développement ressemble à la phase de déploiement que vous avez créée dans le module Créer un pipeline de mise en production dans Azure Pipelines. Vous avez alors utilisé un déclencheur CI pour démarrer le processus de génération. Vous allez en faire autant ici.
Récupérer (fetch) la branche à partir de GitHub
Ici, vous récupérez la branche release
à partir de GitHub. Vous basculez également vers la branche.
Cette branche fait office de branche de mise en production. Elle contient le projet Space Game utilisé dans les modules précédents. Elle contient également une configuration Azure Pipelines qui vous permet de démarrer.
Pour récupérer et basculer vers la branche :
Dans Visual Studio Code, ouvrez le terminal intégré.
Exécutez les commandes
release
suivantes pour récupérer une branche nomméegit
dans le dépôt Microsoft et basculer vers cette branche.git fetch upstream release git checkout -B release upstream/release
Le format de ces commandes vous permet d’obtenir le code de démarrage du dépôt GitHub de Microsoft appelé
upstream
. Dans quelques instants, vous allez envoyer (push) cette branche vers votre dépôt GitHub appeléorigin
.Si vous le souhaitez, ouvrez azure-pipelines.yml à partir de Visual Studio Code. Familiarisez-vous avec la configuration initiale.
La configuration ressemble à la configuration de base que vous avez créée dans le module Créer un pipeline de mise en production avec Azure Pipelines. Elle génère uniquement la configuration de mise en production de l’application. Pour les besoins de cette formation, cette configuration n’exécute pas les vérifications de qualité ou de sécurité que vous avez configurées dans les modules précédents.
Notes
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 requête de tirage (pull request), lorsque vous disposez d'une version Release Candidate, ou lorsque vous fusionnez du code sur la base de type primaire.
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 des changements vers la phase de développement
Dans cet exercice, vous modifiez la configuration de votre pipeline pour promouvoir la build vers la phase de développement.
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. Avec votre équipe, vous aviez alors créé une preuve de concept pour le déploiement continu. Notez cependant les différences 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 l’ensemble du pipeline. Elles définissent la configuration à générer (
Release
). Elles 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.
- Elle utilise une condition qui indique au système d’exécuter la phase uniquement si la phase précédente a réussi et si la branche actuelle est
release
. Cette configuration garantit que les fonctionnalités de mise en production sont déployées uniquement sur l’environnement de développement. - L’étape de déploiement utilise la variable
WebAppNameDev
pour effectuer le déploiement sur l’instance d’App Service associée à l’environnement de développement.
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 changements vers la phase de développement à partir de plusieurs branches telles querelease
etmain
.- Cette configuration définit des variables au début du fichier. Les variables sont utilisées dans l’ensemble du pipeline. Elles définissent la configuration à générer (
À partir du terminal intégré, ajoutez azure-pipelines.yml à l’index. Validez ensuite le changement et poussez-le vers GitHub.
Conseil
Enregistrez azure-pipelines.yml avant d’exécuter ces commandes Git.
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 l’exécution terminée, sélectionnez le bouton de retour pour revenir à la page de résumé.
Vous voyez que le déploiement s’est terminé sans erreur.
Dans un navigateur web, accédez à l’URL associée à l’instance d’App Service de 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, sur la page des détails App Service.
Vous voyez que le site web Space Game est déployé sur App Service et qu’il est en cours d’exécution.
Si vous le souhaitez, dans Azure Pipelines, sélectionnez Environnements. Ensuite, sélectionnez l’environnement de développement dev.
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.