So a very basic question … If I have “web site A” and “web api B” in two different .net solutions in the same repo and I want to deploy both at the same time to IIS on a server. Is there a way to design the yaml pipeline to only deploy A if there’s been a commit/change in the artifacts and only deploy B if there’s similarly been a change? Currently our pipeline unintelligently deploys both A and B unconditionally if there’s a change to A or to B.
I’m confused - are you wanting to deploy both at the same time or deploy them independently of each other?
You say the same time, but then you describe an independent process for each.
Sorry. I want to deploy them with the same button click. If they run in parallel or serially, it doesn’t matter so much. It’s really more of a question to see how I can deploy both with one button click but only have the deployment steps run if there was a change to the code. I guess an alternative is to chain pipelines.
Something like this:
https://pumpingco.de/blog/run-an-azure-pipelines-job-only-if-source-code-has-changed/
Right now we have two repos, one for “web site A” and one for 'web api B". They deploy independently. The argument against putting them into the same repo is, “if you do that, then we need to deploy everything everytime that there is a change to either A or B”.
You can have numerous items in the same repo and have separate pipelines defined with path filters on those pipelines.
So on the same lines … what do you use as your criteria of put A into it’s own repo and B into it’s own repo? I have heard some people say, “It depends on whether they have to be deployed together as a single unit”. Others have said, “It depends only on the cohesiveness of the code”, which is a bit more fuzzy.
That article looks great, btw. I’m going to try it out.
I put products in a single repo. Google puts everything in a single repo. Other people put every single deployable item in its own repo.
Thanks again, it’s very helpful.
