My team builds a .NET based software and several other components. Currently using TeamCity to do the continuous integration, MSBuild for simply compiling .sln file (plus some other small tasks such as unit tests).
Our source control is structured in a way, such that the repo contains many small “plugin” projects that get compiled after a single commit.
This makes it hard to only build only the changed components, but also to deliver only those later on as build artifacts.
Solutions such as setting the build target to “Build” instead of “Rebuild” may assist here, but it seems a bit too fragile, especially when dealing with a distributed build environment where the build may be carried on any number of build “agents”, even ones that don’t have the previous compilation output on them.
I am wondering what’s the correct way to tackle this scenario? Obviously this is a known issue that’s probably been handled and is handled by many.
We’d like to build and deliver (per build) a set of DLLs/components that were modified by the current build (by the code checkin).
What techniques can we implement to achieve this?
One solution is “build” instead of “rebuild”.
If the builds runon multiple agents,then archive the build artifacts at the end of the build process at a shared location and copy those artifacts to the buildworkspace at the beginning of the next build (ie., automate archiving the artifacts at the end of he build and copying it at the starting of he build). The first build will fail because there will be no artifacts to copy from…hence keep that step as continue on failure or manually create that before. Running he first build.
This will definitely increase he build time by a min or two….so ensure that the shared location is in the same network as your build agents…