Background: C# .NET in TFS2015 and VC source control. CI using TFSBuilds. Internal Proget server, already publishing Nuget packages from other TFSBuilds.
I am looking to move a collection of framework projects into their own Git repo. Below is a sample of it's structure for reference.
Framework.sln
IO.proj
Logging.proj
Other.proj
My confusion comes from how to design the CI build(s?) so that only those projects that have been changed will get new packages published. Currently I have a CI build that builds the Framework.sln, and then packages and publishes all outputs from that to Proget, incrementing the package version using BuildNumber.
Obviously this is an issue as a single change to Logging.proj will kick off the CI build and I end up with a new version of each package published even though there is only a change to 1. Before we switched to TFSBuild we had MSBuild running bitdiffer to compare differences and increment version numbers automatically.
What I'm wondering is do I have to have a CI build per project, can TFS handle this scenario using something else, or am I missing something very obvious.
Note: I have left the branching strategy out of all this as I don't think it matters, whatever way branches are managed this issue will still occur, but if I'm wrong then let me know.
You can set the VSTS/TFS build to only occur when changes happen in a specific path or folder, so in your case you may end up with 3 builds building each individual project