CI / CD管道作为YAML定义的骨架

Question

我正在尝试为Azure DevOps中的简单CI / CD管道创建yaml定义文件。

我的管道应如下所示：

1. 是否可以在一个具有不同阶段和工作的定义文件中定义整个工作流程？

2. 如何确定已更改哪个项目（哪个GIT子路径触发了构建）以继续进行项目A / B工作流？

3. 项目A的第一个工作流程对我来说似乎是可行的。我可以与sc或runsas一起运行psexec命令以启动/停止服务并使用复制文件任务。但是如何启动ASP.NET Web应用程序发布到本地目录（就像我对VS-> Publish-> Local Folder所做的那样）？

4. 在那之后，我猜想这是利用脚本替换内容，安装npm软件包以最小化和捆绑js / css文件并将其上传到ftp服务器的最简单方法。还是任何更好/更轻松的想法？

如果你们可以通过为工作流创建一个初始yaml定义来支持我，而没有任务的详细信息，我将非常感谢。如果您能回答上面的问题，也许我会更加清楚。

目前，我有一个非常简单的初始构建文件：

# ASP.NET
# Build and test ASP.NET projects.
# Add steps that publish symbols, save build artifacts, deploy, and more:
# https://docs.microsoft.com/azure/devops/pipelines/apps/aspnet/build-aspnet-4

trigger:
- master # for a productive deployment after manual approval
- develop # for a automatic test deployment

pool:
  vmImage: 'windows-latest'

variables:
  solution: '**/*.sln'
  buildPlatform: 'Any CPU'
  buildConfiguration: 'Release'

steps:
- task: NuGetToolInstaller@0

- task: NuGetCommand@2
  inputs:
    restoreSolution: '$(solution)'
    feedsToUse: 'select'
    vstsFeed: 'tpcemedia'

- task: VSBuild@1
  inputs:
    solution: '$(solution)'
    msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactStagingDirectory)"'
    platform: '$(buildPlatform)'
    configuration: '$(buildConfiguration)'

Answer 1

1. 否，yaml尚无法发布。您可以进行构建阶段\工作，但是在这种简单情况下使用它们是没有意义的

2. Yaml具有path-trigger filter，只需为每个应用程序配置一个构建即可。无需使构建条件复杂化。做这样的事情：

build1：

trigger:
  paths:
    include: src/proj1/*

build2：

trigger:
  paths:
    include: src/proj2/*

1. 最好将发布和构建分开，这样，发布代理将直接位于服务器上，并且能够在本地重新启动服务，而无需访问网络（及其更安全）。它还将“免费”提取由构建代理生成的工件。

2. 为什么使用ftp，只需使用“发布工件”步骤，就容易得多。