-1

I have a "SOA" styled application, with a single solution containing almost 100 individual projects (which are a solution within them, i.e. they can be run independently). I have created a build and release definition in TFS 2018 and everything works perfectly. The issue is if I make changes to a single service (out of 100), and check-in my code, the build definition is triggered which builds the entire application and then the release definition deploys the entire thing(100+) each time. I don't want it. I need it to be specific to the service in which changes are made. Is there any way to do it? Creating multiple build/release definition which is tied to the specific path of each service should solve it but I don't want to go down that road, because I will end up creating 100's of definitions. Is there any other way to do it?

This is for a .Net application, hosted in TFS 2018 (On-premise).

The solution structure is as below:

AllWCFService.sln
  |_Service1.csproj 
  |_Service2.csproj
  |..
  |..
  |_Service100.csproj

Each Service can also be run and hosted independently.

This is my first question here. I apologize for any confusion.

Sagar Dutta
  • 1
  • `The issue is if I make changes to a single service (out of 100), and check-in my code, the build definition is triggered which builds the entire application and then the release definition deploys the entire thing(100+) each time.` Sorry not totally get the point about this part, if the changes is out of 100 , did you mean it not belong any ServiceX. csproj project under your solution? If so, how did you know it should deploy which particular service in this scenario? Or you just want changes in Service1.csproj , only build Service1.csproj and only deploy the build artifacts of it? – PatrickLu-MSFT Sep 10 '19 at 07:53
  • @PatrickLu-MSFT No the service is under the solution. To answer your other question: "Or you just want changes in Service1.csproj , only build Service1.csproj and only deploy the build artifacts of it?". Yes, this is exactly what I'm looking for. Although the Service1 is a part of the AllWCFService solution, I do not want to deploy all 100 services (with literally no changes to them) once again. I just want to build and deploy the service(s) which were modified.I want my build/release definition to identify and deploy only those project(s), not everything. I'm sorry for any confusion. – Sagar Dutta Sep 11 '19 at 03:38
  • Hi Sagar Dutta, just checking to see if the information provided was helpful. If my reply helped or gave a right direction. Appreciate for a vote or [marking it as an answer](https://meta.stackexchange.com/questions/5234/how-does-accepting-an-answer-work) which will also helps others in the community. – PatrickLu-MSFT Sep 19 '19 at 02:39

1 Answers1

0

As you have mentioned, by using Path filters on the Build definition should be the easiest solution.

With the proper path to the project in the Path filter only the proper Builds spin up, and any projects untouched do not trigger a build. Each build has it's own release which then deploys the specified app to it's own destination. As a ugly workaround, you could set up a group each with 5 services which will reduce 100's of definitions to 20's.

Otherwise, you have to customize your build definition/pipeline. Use some scripts to determine or judge which part of your Servicex.csproj changed base on your name.

Then call msbuild with /t option to build a single or multiple projects. 

msbuild test.sln /t:project;project2 /p:Configuration="Release" /p:Platform="x86" /p:BuildProjectReferences=false

specify project file of a solution using msbuild

It will only build specified changed project and generated corresponding artifacts. Then add scripts in release to specify path according build generated artifacts to deploy each service.

Hope this helps.

PatrickLu-MSFT
  • 49,478
  • 5
  • 35
  • 62