Skeleton for a CI/CD pipeline as YAML definition - azure-devops

Question

I'm trying to to create a yaml definition file for a simple CI/CD pipeline in Azure DevOps.
My pipeline should look like this:
Is it possible to define the whole workflow in one definition file with different stages and jobs?
How can I determine which project (which GIT sub-path has triggered the build) has changed to proceed with project A/B workflow?
The first workflow with project A seems feasible for me. I can run the sc command together with runsas or psexec to start/stop the service and use a copy file task. But how can I initiate to publish the ASP.NET web application to a local directory (as I would do with VS->Publish->Local Folder)?
After that I guess it's the easiest way to make use of scripts to replace content, install npm packages to minify and bundle js/css files and upload these to a ftp server. Or any better/easier ideas?
If you guys can support me by creating an initial yaml definition just for the workflow without the details of the tasks I would really appreciate that. Maybe I get a more clear vision if you can answer my questions above.
At the moment I have a very simple initial build file:
# ASP.NET
# Build and test ASP.NET projects.
# Add steps that publish symbols, save build artifacts, deploy, and more:
# https://learn.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

No, releases are not yet possible in yaml. You can have build stages\jobs, but it makes no sense to use them in such a simple case
Yaml has a path-trigger filter, just configure a build per application. no need to complicate the build with conditions. do something like this:
build1:
trigger:
paths:
include: src/proj1/*
build2:
trigger:
paths:
include: src/proj2/*
Better to separate release and build, this way your release agent will be directly on the server and would be able to restart service locally without the need to have network access (and its more secure). It would also pull the artifacts generated by the build agent "for free".
Why use ftp, just use "publish artifacts" step(s), much easier.