【问题标题】:ASP.NET Core + Angular deploy Artifact with Azure DevOps release pipelineASP.NET Core + Angular 使用 Azure DevOps 发布管道部署工件
【发布时间】:2020-07-17 07:31:14
【问题描述】:

我用 Angular 创建了一个 asp.net 核心项目。所以它是 1 个单声道应用程序而不是两个应用程序。

我的问题如下:

我应该选择部署哪个包/文件夹? Dist 文件夹还是 zip 文件?还是名为“artifactnametest”的文件夹?

【问题讨论】:

  • 这个问题怎么样?下面的答案是否解决了您的问题,如果没有,请告诉我有关此问题的最新信息吗?
  • 它没有解决它,因为还有另一个问题。但我为此提出了一个不同的问题。我会关闭这个。

标签: angular asp.net-core azure-pipelines azure-pipelines-release-pipeline


【解决方案1】:

您应该改为发布您的 asp net core 应用程序。

这是来自我们的一个项目的示例构建文件。这仅适用于 asp.net 核心。对于 Angular 应用,我们会做一些额外的事情,比如在不同的任务中运行 npm install,但原理是一样的。

# ASP.NET Core (.NET Framework)
# Build and test ASP.NET Core projects targeting the full .NET Framework.
# Add steps that publish symbols, save build artifacts, and more:
# https://docs.microsoft.com/azure/devops/pipelines/languages/dotnet-core

trigger:
- master

pool:
  vmImage: 'windows-latest'

variables:
  solution: '**/*.sln'
  buildPlatform: 'Any CPU'
  buildConfiguration: 'Release'
  runtime: 'win-x64'

steps:
- task: NuGetToolInstaller@1

# Restore all nuget packages and .net core tools
- task: DotNetCoreCLI@2
  inputs:
    command: 'custom'
    projects: '**/*.csproj'
    custom: 'restore'
    arguments: '-r $(runtime)'

# Build projects
- task: DotNetCoreCLI@2
  inputs:
    command: 'build'
    projects: '**/*.csproj'
    arguments: '-c $(BuildConfiguration) --no-restore -r $(runtime)'

# Publish all projects to /staging/ci-build/<ProjectName>/
- task: DotNetCoreCLI@2
  inputs:
    command: 'publish'
    publishWebProjects: false
    projects: |
      **/*Client.csproj
      **/*WorkerService.csproj
      **/*Server.csproj
    arguments: '-c $(BuildConfiguration) -o $(Build.StagingDirectory)/ci-build --no-build --self-contained -r $(runtime)'
    zipAfterPublish: false

# Archive the /staging/ci-build folder to /staging/RemoteData.<BuildNumber>
- task: ArchiveFiles@2
  inputs:
    rootFolderOrFile: '$(Build.StagingDirectory)/ci-build'
    includeRootFolder: false
    archiveType: 'zip'
    archiveFile: '$(Build.ArtifactStagingDirectory)/RemoteData.$(Build.BuildNumber).zip'
    replaceExistingArchive: true

# Publish the zipfile as artifact
- task: PublishBuildArtifacts@1
  inputs:
    PathtoPublish: '$(Build.ArtifactStagingDirectory)/RemoteData.$(Build.BuildNumber).zip'
    ArtifactName: 'RemoteData.$(Build.BuildNumber)'
    publishLocation: 'Container'

【讨论】:

  • 感谢您的帮助。但是 dist 文件夹会发生什么?
  • 嗯,您是否尝试过在本地发布您的应用?你可以看到输出是什么样子的
  • "这仅适用于 asp.net 核心。对于 Angular 应用程序,我们会做一些额外的事情,例如在不同的任务中运行 npm install"。但这是一个单声道的应用程序。 asp.net 核心应用程序会执行诸如 ng build -- prod 之类的操作...那为什么要在 te yaml 文件中为此编写更多代码呢?
  • @MYil 只是将它们放入单独的构建任务中。这有助于找出哪些任务需要很长时间。例如 npm update 需要很长时间,所以我们在某个时候应用了缓存; docs.microsoft.com/en-us/azure/devops/pipelines/release/… 除了发布确实会照顾一切。
  • 我能再问你一个问题吗?为什么要发布多个这样的项目?在我的构建管道中,我这样发布: - 任务:DotNetCoreCLI@2 输入:命令:'publish' publishWebProjects:true 参数:'--configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory)' zipAfterPublish: true
【解决方案2】:

我应该选择部署哪个包/文件夹? Dist 文件夹还是 zip 文件?还是名为“artifactnametest”的文件夹?

我同意普拉森。我们可以将 NPM dist 文件夹从工作目录复制到 staging 目录,然后压缩整个 staging 目录并发布。

或者,我们可以在发布管道中添加两个工件来部署 Dist 文件夹和 zip 文件:

您可以查看此文档Create a build pipeline for Angular and ASP.NET Core apps with Visual Studio Team Services 了解一些详细信息。

【讨论】:

    【解决方案3】:

    我已经使用 Dotnet Build 和 NPM build 完成了这个实现。 首先进行 NPM 构建并生成一个 dist 文件夹。然后做一个 asp.net 构建。构建完成后,将文件复制到 Build.artifactstaging 目录。 同样,对于 NPM dist,将文件夹从工作目录复制到要保持不变的文件夹内的暂存目录。 然后,您可以压缩整个暂存目录并发布相同的内容。下面是示例代码 sn-p。您可以用 DotNetCore@2 任务代替 MsBuild

        trigger:
            branches:
              include:
              - master
          
        pool:
          name: Azure Pipelines
          vmImage: 'windows-2019'
          demands:
            - npm
            - msbuild
            - visualstudio
        
        variables: 
          configuration: release
          BuildConfiguration: "Release"
          platform: x64
        
        stages:
        - stage: Build
          jobs:
          - job: Build
            steps:
            - task: NuGetToolInstaller@0
              displayName: 'Use NuGet 4.4.1'
              inputs:
                versionSpec: 4.4.1
            - task: NuGetCommand@2
              displayName: 'NuGet restore'
              inputs:
                restoreSolution: '$(Parameters.solution)'
                vstsFeed: '34356gsgv643a'
            - task: Npm@1
              displayName: 'npm install'
              inputs:
                workingDir: angularfoldername
                verbose: false
            - task: Npm@1
              displayName: 'npm custom'
              inputs:
                command: custom
                workingDir: angularfoldername
                verbose: false
                customCommand: 'run build'
            - task: MSBuild@1
              displayName: 'Build solution dotnet.csproj'
              inputs:
                solution: dotnet.csproj
                msbuildArguments: '/t:build /p:outputpath="$(build.artifactstagingdirectory)" /property:langversion=latest'
            - task: DotNetCoreCLI@2
              displayName: Test
              inputs:
                command: test
                projects: '$(Parameters.TestProjects)'
                arguments: '--configuration $(BuildConfiguration)'
            - task: CopyFiles@2
              displayName: 'Copy Files to: $(build.artifactstagingdirectory)\_PublishedWebsites\dotnet\angularfolder'
              inputs:
                SourceFolder: 'angularfoldername'
                Contents: '**'
                TargetFolder: '$(build.artifactstagingdirectory)\_PublishedWebsites\dotnet\angularfoldername'
               - task: PublishBuildArtifacts@1
              displayName: 'Publish Artifact: drop'
              inputs:
                PathtoPublish: '$(Build.ArtifactStagingDirectory)\_PublishedWebsites'
    

    【讨论】:

    • 压缩 dist 文件夹和 asp.net core 文件夹时会发生什么?我部署它,然后呢? Azure Web 服务如何知道如何处理它们?
    • 如果我理解正确,您正在尝试独立压缩两个文件夹。是的,这是可能的,但在这种情况下,部署将单独进行。示例:您部署后端(Dotnetcore)。现在在前端部署期间,您将定义虚拟目录路径,Azure DevOps 将部署文件夹(dist)。部署的时候会自己解压,但是如果我们一起部署就不需要单独压缩dist
    猜你喜欢
    • 2022-12-05
    • 1970-01-01
    • 2020-07-04
    • 1970-01-01
    • 1970-01-01
    • 2021-02-27
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多